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ABSTRACT 


This  report  presents  the  results  of  a review  of  approximately 
600  Equipment  Performance  Reports  generated  during  developmental 
testing  of  the  AN/TSQ-112  Tactical  Communications  and  Emitter  Iden- 
tifieation  System  (TACELIS).  The  methodology  for  developmenting 
reliability  values  from  a data  base  of  incident  reports  is 
explained.  Reliability  values  are  given  for  the  entrie  system, 
its  major  assemlies,  and  the  Line  REPLACEABLE  Units  of  the  system. 
Formulas  are  developed  for  computing  reliability  values 
coresponding  to  any  defined  state  from  operation  of  the  TACELIS 
system.  The  reliability  growth  of  the  system  components  during  th 
e test  period  though  represented  by  the  particular  data  base 
studied  is  analyzed.  Recommendations  are  given  for  improving  the 
hardware-related  reliability  of  the  TACELIS  system.  Suggested 
improvements  to  the  information-gathering  practices  and  data 
analysis  procedures  employed  during  developmental  testing  are 
outlined. 
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This  re|x3rt  presei\ts  the  results  of  a review  of  Equipment  Ferformance 
Re{x>rts  qenerated  durinq  developmental  testinq  of  the  AN/TS^^-112  Tactical 
Communications  and  Emitter  Identification  System  (TACEl.IS) . The  work 
described  in  this  document  was  performed  for  the  D.S.  Army  Siqnals  Warfare 
Laboratory,  Vint  Mill  Farms  Station,  Warrenton,  Virqinia,  under  Contract 
DAEA18-72-0005-D302. 

Technical  direction  for  this  contract  was  provided  by  Mr.  Dave  Fatty 
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FXDREWORD 


This  report  presents  the  results  of  a review  of  Equipment  Performance 
Reports  generated  during  developmental  testing  of  the  AN/TSQ-112  Tactical 
Communications  and  Emitter  Identification  System  (TACELIS) . The  work 
described  in  this  document  was  performed  for  the  U.S.  Army  Signals  Warfare 
Laboratory,  Vint  Hill  Farms  Station,  Warrenton,  Virginia,  under  Contract 
DAEA18-72-0005-D302. 

Technical  direction  for  this  contract  was  provided  by  Mr.  Dave  Patty 
of  the  Signals  Warfare  Laboratory. 
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ABSTRACT 
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This  report  presents  the  results  of  a review  of  approximately  600 
Equipment  Performcuice  Reports  generated  during  developmental  testing  of 
the  AN/TSQ-112  Tactical  Communications  and  Emitter  Identification  System 
(TACELIS) . The  methodology  for  developing  reliability  values  from  a data 
base  of  incident  reports  is  explained.  Reliability  values  are  given  for 
the  entire  system,  its  major  assemblies,  and  the  Line  Replaceable  Units 
of  the  system.  Formulas  are  developed  for  computing  reliability  values 
corresponding  to  any  defined  state  of  operation  of  the  TACELIS  system. 

The  reliability  growth  of  the  system  components  during  the  test  period 
represented  by  the  particular  data  base  studied  is  analyzed.  Recommenda- 
tions are  given  for  improving  the  hardware- related  reliability  of  the 
TACELIS  system.  Suggested  improvements  to  the  information-gathering 
practices  and  data  analysis  procedures  employed  during  developmental 
testing  are  outlined. 
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CHAVTEF  ONE 


INTRODUCTION 


1 . 1 BACKGROUND 

The  U.S.  Army  is  in  tho  process  of  developing  the  Tactical  Communica- 
tions and  Emitter  Identification  System  (TACELIS) . The  TACELIS  system  is 
part  of  a larger  intelligence-gathering  and  communications- jamming  complex 
designated  TACOM-EW.  The  TACOM-EW  system  is  deployed  in  several  Army 
vehicles  and  shelters  near  the  Forward  Edge  of  the  Battle  Area  (FEBA)  to 
gather  intelligence  from  the  interception  of  enemy  communications  and  to 
control  active  jamming  of  these  signals.  The  TACELIS  system  hardware 
includes  more  than  130  different  Line  Replaceable  Unit  (LRU)  types,  con- 
sisting of  both  CKivernment  Furnished  Equipiments  (GFE)  and  contractor- 
developed  items.  Several  different  software  applications  packages  hosted 
by  various  computers  control  the  operation  of  the  system. 

The  TACELIS  system,  at  full  equipment  strength,  is  comjxised  of: 

• A Control  and  Processing  Center  (CPC) , which  includes  23  operator 
stations,  each  served  by  a Cathode  Ray  Tube  (CRT)  display.  The  CPC 
equipment  is  contained  in  four  large  vans. 

• Two  Remote  Master  Stations  (RMSs) , each  deploying  sheltered  elec- 
tronic equipment  and  an  antenna  supfx>rt  vehicle  carried  in  four 
trucks  and  a cargo  van. 

• Eight  Remote  Slave  Stations  (KSSs),  eacli  including  electronic 
eguifiment  and  otlier  hardw.»re  sheltered  in  a tracked  vehicle. 

The  TACELIS  communications  intelligence-gathering  system  is  currently 
undergoing  developmental  testing  at  the  U.S.  Army  Electronic  Proving  Ground 
at  Fort  Huachuca,  Arizona.  Table  1-1  lists  the  seven  Army  agencies  involved 
in  the  materiel  development  process  for  the  TACELIS  system. 

The  U.S.  Army  Signals  Warfare  Laboratory,  as  Materiel  Developer  for 
the  TACELIS  system,  has  placed  ARINC  Research  Corjvsration  under  contract 
to  review  the  hardware  maintenance  data  from  the  first  11  months  of  develop- 
mental testing. 
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Table  1-1.  U.S.  ARMY  AGENCIES  PARTICIPATING  IN  ACQUISITION  OF  THE 
TACELIS  SYSTEM 

Agency  Function 

U.S.  Army  Agency 

Materiel  Developer 

Signals  Warfare  Laboratory  (SWL) 

Vint  Hill  Farms  Station 

Warrenton,  Virginia 

Developmental  Tester 

U.S.  Army  Electronic  Proving  Ground 
(USAEPG) 

Fort  Huachuca,  Arizona 

Developmental  Evaluator 

Test  and  Evaluation  Command  (TECOM) 

Aberdeen , Mary 1 and 

Combat  Developer 

Training  and  Doctrine  Command  (TRADOC) 

Fort  Monroe,  Virginia 

Combat  Developer/ 
Proponent 

U.S.  Army  Intelligence  Center  and  School 
(USA ICS) 

Fort  Huachuca,  Arizona 

Operational  Evaluator 

Operational  Test  and  Evaluation  Agency 
(OTEA) 

Bailey's  Cross  Roads,  Virginia 

RAM/Logistics  Advisor 
to  Combat  Developer 

U.S.  Army  Logistics  Center  (USALOCa.'') 

Fort  Lee,  Virginia 

Army  Regulation  70-10  states  the  concept,  assigns  responsibilities, 
establishes  policies,  and  prescribes  procedures  for  test  and  evaluation, 
and  provides  information  for  use  at  decision  reviews  during  the  materiel 
acquisition  process,  in  implementation  of  PoD  Directive  5000.. 1 and  in 
consonance  with  the  provisions  of  Army  Regulation  No.  1000-1. 

Testir  ■'  is  conducted  (1)  to  demonstrate  how  well  the  materiel  system 
meets  its  technical  and  operational  requirements;  {'2)  to  provide  data  for 
assessing  developmental  and  operational  risk  in  decision-making;  (3)  to 
verify  that  the  technical,  operational,  and  supiKirt  problems  identified  in 
previous  testing  have  been  corrected;  and  (4)  to  ensure  that  all  critical 
issues  to  be  resolved  by  testing  liave  been  adequately  considered. 

Testing  is  divided  into  two  basic  categories  — developmental  testing 
and  operational  testing  — as  described  in  Army  Regulations  1000-1  and  71-3, 
respectively.  Developmental  testing  is  the  testing  and  evaluation  conducted 
to  demonstrate  that  the  engineering  design  and  development  pi'ocess  is  com- 
plete, that  the  design  risks  have  been  minimized,  and  that  the  system  will 
meet  specifications  --  as  well  as  to  estimate  the  system's  military  vitility 
when  it  is  introduced. 
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Developmental  testing  is  planned,  conducted,  and  monitored  by  the 
Materiel  Developer  and  is  accomplished  in  a p>rovinq  ground  environment. 

It  includes  engineering  design  testing  and  human  factors  testing  to 
demonstrate  a satisfactory  technical  man-machine  interface,  using  qualified 
and  experienced  oi'erators,  crecs,  and  maintenance  support  personnel. 

As  Materiel  Developer  for  the  TACELIS  system,  the  Signals  Warfare 
Laboratory  is  tasked  with  demonstrating  that  the  Reliability,  Availability, 
and  Maintainability  (RAM)  goals  for  the  system  can  be  achieved.  These 
goals  are  define<i  in  terms  of  the  total  system  and  the  three  major  assem- 
blies constituting  the  system.  (;)uant  itat  ive  RAM  requirements  for  the 
TACELIS  system  are  specified  in  Appendix  A of  the  TACELIS  Purchase  Descrip- 
tion AS-Oll-72,  Revision  A,  1 June  1972.  These  requirements  are  piresented 
in  Table  1-2. 

The  data  base  for  determining  whether  the  assigned  goals  can  be 
achieved  consists,  in  part,  of  detailed  Maintenance  Request  forms  that 
are  generated  for  every  controlled  maintenance  action  and  for  each  modifi- 
cation incorporated  during  develo^imental  testing.  Data  from  these  forms 
are  compiled  on  Equif>ment  Perfonnance  Report  forms,  which  are  evaluated  at 
a scorina  .;onference  attended  by  the  participating  Army  agencies.  RAM 
statistics  are  derived  from  the  evaluated  data  in  accordance  with  Army 
Regulation  702-3  and  M1L-STD-721B. 


rahie  1-2.  TACELIS 

RECUT  REMENTS 

Assembly 

Mean  Time 

Mean  Time 

Aval  lability 

Between  Failures 
(Hours) 

to  Repair 
(Hours) 

(Inherent ) 

Total  System 

100 

100 

.9680 

Control  and 

Processing 

Center 

400 

60 

1 

.9975 

Remote  Master 
Station 

200 

1 

100 

.9825 

Remote  Slave 
Station 

200 

100 

1 

.9825 

1.2  OBJECTIVE 

The  objective  of  this  study  is  to  calculate  RAM  statistics  for  the 
total  TACELIS  system,  its  major  assemblies,  and  its  Line  Replaceable  Units 
(LRUs).  Candidate  LRUs  for  increasing  system  reliability  are  identified. 
Changes  to  improve  reliability  documentation  during  further  testing  are 
recommended.  In  addition,  certain  analytic  techniques  tliat  may  extend  the 


tat ist leal  piodictions  and  assessments  of  TACKLIS  RAM  perfonnance  are 
develofH’d  and  evaluated.  These  same  techniques  will  provide  the  means 
tor  identifyinq  critical  system  deficiencies  and  evaluating  design 
alternat ives . 


1 . i APPROACH 

Ki'i  develofmental  testing  of  the  TACKI.IS  system,  the  maior  assembly 
tyjies  wi'te  deployed  in  the  following  quantities: 

• Control  and  Pri>cessing  Center  (CPC)  1 

• RenK’te  Master  Station  (RMS)  2 

• Remi.'te  Slava*  Station  (RSS)  4 

Approximately  bOO  Equiv'Cient  Perfoimance  Ket'oit  forms  Ivad  already  been 
generated  during  developmental  testing  of  the  TACEMS  system  at  the  start 
of  this  .study.  This  Ixiundt'd  set  is  the  dat.i  base  fc>i'  the  results  presented 
in  this  rejmrt. 

The  RAM  values  associated  with  TACELIS  system  elements  have  been 
developed  from  an  analysis  of  the  data  base.  Reliability  block  diagrams 
for  the  major  assemblies  have  been  used  for  computing  assembly  reliability 
and  for  studying  assembly  sensitivity  to  selected  units.  Tlie  reliability 
of  the  total  system  has  been  studied  on  the  basis  of  a time  history  of 
assembly  failures. 

1.4  REPORT  ORC.AN I NATION 

This  repoit  is  organized  so  tliat  the  analysis  of  RAM  statistics  begins 
at  the  simplest  level,  the  Line  Replaceable  Units:  increases  in  complexity 
with  an  analysis  of  the  major  assemblies:  and  finally,  deals  with  the  total 
system.  The  concepts  and  definitions  to  be  used  are  described  in  Chapter 
Two.  In  Chapters  Three,  Four,  and  Five,  the  RAM  analysis  proceeds  through 
the  three  system  levels.  Chav'ter  Six  presents  a method  for  quantitatively 
discussing  system  states  having  degraded  operational  capability.  Reliability 
growth  is  analyzed  in  Chapter  Seven.  Chapter  Eight  suggests  changes  for 
maximizing  RAM  analysis  opportuivit  ies  during  system  testing.  Ch.apters  Nine 
and  Ten  present  the  conclusions  and  recommendat ions , respectively. 
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CHAPTER  TWO 


CONCEPTS  AND  DEFINITIONS 


This  chapter  presents  the  conceptual  framework  within  which  reliability 
parameters  are  defined  as  used  in  this  report. 


2.1  AREAS  OF  RESPONSIBILITY 

All  agencies  that  participate  in  the  development,  use,  and  maintenance 
of  a system  contribute  to  the  effectiveness  of  the  deployed  system.  There- 
fore, two  steps  must  be  taken  to  give  numerical  descriptions  and  make 
quantitative  predictions  about  system  effectiveness. 

• The  responsibilities  of  each  participating  agency  with  respect  to 
the  system  must  be  identified. 

• Parameters  that  can  be  derived  from  data  describing  system  response 
in  operational  situations  must  be  defined  to  serve  as  figures  of 
merit  for  the  success  of  participating  agencies  in  contributing  to 
system  effectiveness. 

The  following  areas  of  responsibility  may  be  identified  in  the  develop- 
ment and  operation  of  a system: 

• Definition  of  system  requirements 

• Technical  specifications 

• Engineering  design 

••  To  meet  functional  requirements 
••  To  facilitate  use 

••  To  allow  convenient  maintenance,  repair,  and  replacement 

• Manufacture 

• Assembly 

• Definition  of  logistic  support 

• Use 

• Maintenance  and  repair 


ii, 
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Mt'etinq  these  responsibilities  is  essential  to  the  deployment  of  an 
effective  system.  The  requirements  for  the  system  must  be  accurately 
identified.  Technical  specifications  must  be  prepared  so  that  a system 
meeting  those  specifications  will  indeed  be  capable  of  fulfillinq  opera- 
tional requirements.  The  desiqn  must  quarantee  that  the  functional  require- 
ments of  the  system  are  met. 

Ease  of  maintenance,  repair,  and  replacement  considerations,  as  well 
as  convenience  of  use,  should  influence  the  desiqn  of  the  system.  The 
hardware  conf iqurat ion  should  be  convenient  to  service  durinq  scheduled 
nv» intenance . Parts  likely  to  require  the  most  frequent  repair  or  replace- 
ment should  be  desiqned  to  be  the  most  accessible. 

System  desiqn  can  also  influence  the  ease  of  manufacturing  and  assembly 
processes.  These  two  processes  have  been  addressed  separately  in  this  sec- 
tion to  permit  a distinction  between  parts  created  specifically  for  system 
use  and  off-the-shelf  and/or  ckivet  iimt'nt-furnished  equipment  incorporated 
into  the  system.  The  manufactur inq  and  assembly  processes  must  be  success- 
ful in  achieving  the  design  specifications  for  the  system. 

Finally,  the  effectiveness  of  an  existing  system  depends  on  the  situa- 
tion in  which  it  is  used,  maintained,  and  supported.  The  users  of  the 
system  must  be  trained  to  use  it  properly.  Maintenance  personnel  must 
also  have  appropriate  training,  as  well  as  all  necessary  tools,  sufficient 
spare  parts,  and  an  adequate  work  area.  The  logistic  sup^xDrt  of  the  system 
must  be  defined  to  maximize  the  effectiveness  of  the  maintenance  personnel. 

Durinq  developmental  testing  of  the  TACELIS  system,  the  areas  of 
responsibility  must  bo  met  by’  the  vendor,  the  DeveloiTOental  Tester,  and 
the  Materiel  Developer.  How  well  each  area  of  responsibility’  is  met  can 
be  determined  by  an  analysis  of  data  describing  system  operation.  Of 
piarticular  interest  are  all  those  occasions  on  which  the  system  fails  to 
meet  operational  demands. 

The  impact  of  all  these  areas  of  responsibility  can  be  measured  in 
terms  of  two  variables  — cost  and  time.  It  is  not  within  the  scope  of 
this  report  to  deal  with  concepts  of  cost-effectiveness.  The  following 
discussion,  therefore,  will  develop  p'arameters  describing  system  effective- 
ness in  terms  of  calendar  time  that  elapses  durinq  the  existence  of  the 
completed  system. 

2.2  PARAMETERS  REIATING  TO  TIME 

The  time  relationships  that  may  be  described  for  the  purpose  of  defin- 
ing parameters  relating  to  system  effectiveness  are  presented  in  MIL-STD- 
721B,  25  August  1966  (with  Change  Notice  1,  10  Marcli  1970).  Figure  2-1 
illustrates  these  time  divisions  and  shows  all  tliat  time  in  which  the 
following  conditions  prevail: 

* Use  of  the  system  is  not  required 

• The  system  is  on  alert  status 
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• The  system  is  being  brought  into  operation 

• The  system  is  performing  its  function,  or  mission,  successfully 

• The  system  is  down 

From  Figure  2-1,  the  following  time-related  parcimeters  can  be  defined: 


• Mean  Time  Between  Failures 
(MTBF) 

• Mean  Time  To  Repair  (MTTR) 


• Mean  Time  Between 
Maintenance  (MTBM) 


Upt ime 

Number  of  Failures 


Corrective  Maintenance  Time 
Number  of  Corrective  Maintenance 
Actions 


Uptime 

Number  of  Preventive  and  Corrective 
Maintenance  Actions 


• Mean  Maintenance  Time  (MMT) 


Maintenance  Time 

Number  of  Preventive  and  Corrective 
Maintenance  Actions 


• Inherent  (or  Intrinsic) 
Availability 

• Achieved  Availability 


• Operational  Availability 


Uptime 

Uptime  + Corrective  Maintenance  Time 

Uptime 

Uptime  + Maintenance  Time 

Upt ime 

Uptime  + Downtime 


(All  of  these  concepts  have  been  presented  for  the  sake  of  completeness. 
Sufficient  data  are  not  available  under  this  contract  to  develop  all  of 
these  parameters  for  the  developmental  testing  of  the  TACELIS  system.) 


These  foregoing  definitions  are  composed  as  closely  as  possible  in 
accordance  with  the  following  publications: 

• MIL-STD-721B,  "Definitions  of  Effectiveness  Terms  for  Reliability, 
Maintainability,  Human  Factors  and  Safety” 

• TM  38-750,  "The  Army  Maintenance  Management  System  (TAMMS)" 

• AR  702-3,  "Product  A.ssurance:  Army  Materiel  Reliability,  Availa- 
bility, and  Maintainability" 

• AR  70-10,  "Test  and  Evaluation  During  Development  and  Acquisition 
of  Materiel" 

However,  some  areas  of  aimbiguity  exist  among  these  publications.  In  addi- 
tion, the  concepts  and  definitions  presented  in  these  documents  do  not 
correspond  exactly  to  the  data  collection  situation  for  developmental  test- 
ing of  the  TACELIS  system.  Therefore,  some  differences  exist  between  the 
standard  military  definitions  and  their  usage  in  this  report. 

One  obvious  area  of  difficulty  is  that  during  developmental  testing 
both  uptime  and  downtime  constitute  the  total  demand  time  for  the  system. 
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The  demand  time  oeeurs  dniinq  the  leqnlai  test  day  werk  shift  of  about  H 
hours.  Modification  time  (althouqli  it  may  be  considered  active  t im»') 
usually  occurs  at  niqht,  when  no  demands  are  beinq  made  on  the  system, 
and  therebtie  is  not  ixinsidered  a part  of  downtime. 

In  all  deployment  situations,  del.iy  time,  modification  time,  and,  to 
some  extent,  pjt'ventive  maintenanci'  time  are  deferred  wherever  [xissible  to 
that  seqment  of  tlu'  I'alend.ir  in  which  no  demands  are  beinq  made  on  the  sys- 
ti'm.  Sini-e  the  det  ei  mi  nat  ii>n  of  failure  in  practice  frequently  rests  on 
tlr»'  ilemand  status  of  the  systr-m,  the  time  divisions  presented  in  MIL-STD- 
7.;ih  are  niit  iMmpletely  represeirtat  i v«- . By  dividinq  active  time  into 
demand  and  nondemauil  tim»',  some  diffii-ulty  miqht  be  resolved.  Clarifica- 
tion wouUl  also  result  from  par  titioninq  iiuict  ivt'  t im'  into  fr-oe  tinn'  and 
.sforaqj'  timf. 

The  definitions  qiven  in  TM  foi  prt'vrnt  ivi'  m.i  i nf  tviancr'  m.in-fhujrs 

aiul  .ic'fivc  tt'p.iir  m.i  i ritm.irii-i'  ni.  in -hours  correspond  closely  to  the  provt'iit  ivt' 
m.t  I ntoruirh-t'  f /mo  and  oorroi’t  ; i-o  m.i  i ntt'n.inoo  t imi.'  of  Ml  h-STb-721B  and  have 
been  ivnsideied  to  be  eipiivalent  for  I'Valuat  ion  of  data  in  this  study. 
However,  the  definitions  for  aiMi/.iMo  tiiiu',  nonuv.ii  Lthlo  timo,  and  {\issihlc 
(i.ii/s  qiven  in  TM  ,lH-7Si)  do  not  coin'spinui  to  any  of  the  time  cateqories  in 
MIL-STI)-7,.’lH. 

One  .irea  th.it  lem.iins  unresolved  is  the  nuMiiinq  ol  stuiuilni  t into  .is 
used  in  the  di'finition  of  opet.it  ii'ii.i  I .iv.i  i I .ibi  I i t y in  AK  70.1-.1.  For  tliis 
rtqxirt  , it  h.is  been  equ.it  eil  to  nlort  tinif  as  used  in  Ml  l,-STr'-7il  1 B . However, 
some  .inalysts  m.iy  piefi'i  to  extend  the  time  the  systt'm  is  .issumed  oper.ibli' 
into  inuct  ivi'  fimo.  In  .iddition,  there  is  no  formul.i  leported  in  the  Army 
publ  ic.it  ions  revit'wed  for  this  leiiort  dealinq  with  uncompleted  rep.iir 
iictions.  Correct  ivi'  rep.iir  .ict  ions  for  which  complete  documi'iit  at  ion  is 
not  .iv.iil.ible  h.ive  been  omitted  from  the  MTTK  1 cu  1 .i t ion;;  in  this  report. 

2.3  hEVKI.S  OF  ANAI.Y.SIS 

The  discussion  of  t ime-ri' 1 .if  ml  p.ir.imet  ers  .ippl  ii's  to  .iny  defiiu'd  sys- 
tem. The  s.ime  an.ilysis  c.in  be  .ippl  ied  to  the  entire  TACFl.IS  system,  1 1' 
e.ich  of  the  m.iior  .issemblies,  .iiul  to  e.u'h  of  the  l.iiu'  Ki’pl .ice.ibl e Units 
within  the  system.  It  is  only  nei-ess.iry  to  ensure  that  wh.itevei  is  lepoited 
as  .1  failure,  m.i  int  en.ince  .iction,  uptime  .ind  downtime,  etc.,  is  appropriate 
to  the  1 eve  1 be i nq  s t ud i ed . 

Durinq  develoiwi'iital  test  inq  of  the  TACFl.lS  system,  d.it.i  are  beinq 
recorded  for  use  in  computinq  t lu'  time-related  p.ir.imeters  .it  twi'  levi'ls  -- 
the  m.iior  assemlily  and  the  hint'  Kepl.ii-e.ible  Unit  (l.KU)  . The  discussion  of 
incident  c.iteqories  applies  to  d.it.i  .it  the  l.KU  U'vel. 


’.4  INCIDENT  CATEC.CiKIES 


If  a unit  within  a system  lieiiuj  testfii  falls  bi  low  a previously  do- 
finoii  acceptable  level  ot  opt'i  at  ii.)n,  tin-  incidt'ut  is  «ecx>rded;  sulisequent 
evaluation  may  plact>  tin*  incidt-nt  in  one  i>f  these  typical  cateqoiies: 

A.  The  unit  failed  to  meet  the  operational  lequirements  appropriate 
to  its  location  and  funct  ion  within  the  systt'm. 

B.  The  unit  iii>i  not  mi'et  technical  spt'c  i f icat  iitns . 

('.  The  unit  ;.uff»'ied  a failuie  chat  ait  ej  i st  ic  i>t  the  statistical 
distiibution  of  failutt's  with  time  liii  that  ijeneric  typi'. 

D.  The  unit  was  impropetly  used  (includinu  breakaije) . 

E.  The  unit  was  [xioi  ly  maintained  oi  pteviously  not  aiiequately 
repa i red . 

E.  The  unit  was  detective. 

G.  The  unit  was  improperly  assemliled  ot  int'.talled. 

II.  The  incident  was  impioperly  diaqnosed  as  attiibutable  to  this  unit 
when,  in  fact,  it  w.is  the  tesult  ot  a m.i  1 funct  ion  i nq  switch,  fuse, 
IKiwer  supply,  etc.,  ciitical  to  the  unit  but  not  part  of  it. 

These  incident  cateiiories  may  be  s.tudied  ti'  assiqn  i esininsi  bi  1 i ty . 

For  example,  the  tx'pul.it  ion  of  incidents  in  I'atciioiy  C would  definitely 
be  counted  as  failures  in  an  as:u'S!;ment  of  how  successfully  a vendor  had 
met  unit  mean  life  specification.;;  tho.si'  incidents  in  Cateqoiy  M would  not 
be  considered.  Incidents  di'scribed  by  D,  E,  and  C miqht  be  counted  as 
failures  in  a vendor  assessmi'iit  if  they  resulted  from  markedly  {xior  desiqn. 
All  incident  cateqories  are  of  interest  to  the  field  usi'i  of  the  system, 
who  simply  wants  to  know  how  often  he  can  depend  on  the  system  when  he 
needs  it. 

It  can  be  seen  fiom  this  disiussion  that  t la'  time-ielated  paiameters 
previously  defini'd  can  have  si'veial  values  depi'tidiiui  on  evaluation  of  the 
refKirted  incidents.  The  MTBF  value  ii'ix'ited  to  a ix'tential  user  of  the 
system  would  be  quite  diffi'ient  tiom  the  valui'  used  to  determine  the  merit 
of  a vendor's  manufactured  unit. 


2.5  REI.IABIl.lTY,  AVAILABl  I.ITY  , AND  KF.l'Al  KAH  1 1,  ITY 


One  further  step  may  be  taken  in  developinq  fiqures  of  merit  f i om  the 
time-related  parameters.  If  the  number  of  unsclu'du  1 1'd  faituji's  is  taken 
to  be  equal  to  the  number  of  coriective  nvi  i nt  enanci'  actiiins,  then  the 
definition  of  inherent  availability  c.in  ln'  lestated  as  follows: 


Inherent  Availability 


tipt  ime 

Uptime  + Collective  Maintenance  Time 
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Let  U » uptime 

N « number  of  failures,  which  is  assumed  equal  to  the  number  of  repairs 
C ••  corrective  maintenance  time 


Inherent  availability 


In  the  same  way, 


Ach i o ved  av a i 1 ab i 1 i t y 


U/N 

U/N  + C/N 

MTBT  _ 

MTBF  + MTTR 


MTHF  + MMT 


Operational  Availability 


MTBF  + MMT  + MDT 


where 


MDT  = mean  delay  time  (see  Fiqure  2-1) 

If  the  time-related  par;uneters,  MTBF  and  MTTR,  are  assiuned  to  become 
constant  with  time  as  a system  or  a population  of  LRUs  matures,  then  the 
followinq  mathematical  definitions  ate  true: 

• Reliability.  The  probability  that  a system  will  perform  satisfac- 
torily for  at  least  a qiven  period  of  time,  T,  when  used  under 
specified  conditions.  Thus 


Reliability  = exp  j -T  MTBF J 

• Repairability . The  probability  that  a failed  system  will  be 

restored  to  operable  condition  in  a specified  active  repair  time  T. 
Thus 

Repairability  = exp  |-T,'MTBFj 

In  this  study,  the  definitions  specified  in  Sections  2.2  and  2.b  have 
been  used  in  the  analysis  of  TACELIS  develo^wental  test  data. 
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This  chapter  presetits  the  analysis  ot  the  i.iata  describing  the  Line 
Replaceable  Units;  a i.-ompntat  iuna  1 metheil  tt>r  improving  the  analysis  is 
also  suggested. 


3.1  RtigUIRKD  DATA 

The  following  infomation  should  be  available  to  calculate  the  time- 
related  par.uneters  at  the  unit  level  fot  the  TACKLIS  systt'm: 

• A complete  listing  of  the  LRU  types  that  constitute  the  system 

• An  accurate  statemt'nt  of  the  numl'er  of  individual  units  of  each 
type  being  used  .it  any  time  in  eacli  of  the  maior  asst'inblies  of 
the  system 

• A history  of  the  times  foi  which  e.ich  maior  assi'mbly  was  "turned 
on"  or  receiving  iniwer 

• A history  of  all  recordt'd  inciiients  involving  units  in  the  TAOELIS 
system,  incliuling  prevt'iitive  and  cort  t'l-t  i vt'  maintenance 

• The  mainten.ince  timi'  associ.ittnl  witli  iMch  incident 

3.2  ASSUMI'TIONS 

Certain  assumptions  have  been  m.ide  to  dettumine  ttie  use  of  these  data: 

• Malfunction  of  a unit  can  occui  .it  .iny  time  dm  ing  which  the 
assembly  containing  that  unit  is  receiving  ixiwer,  i.e.,  unit 
malfunction  is  defined  not  only  for  the  duration  of  operational 
demand  but  for  all  the  t imi-  the  unit  is  powered  (uptime). 

• All  units  that  failed  during  the  night  (before  0800  hours  on  the 
next  test  day)  have  been  recorded  as  failing  ex.tctly  at  the  beginning 
of  the  next  test  day.  All  units  that  f.iiled  during  weelcend  have 
been  recorded  as  failed  .it  0800  liours  ini  Monday  morning.  (This 

fai  lure-reixirt  ing  proceduit'  results  in  .in  optimistic  estim.ited  value 
of  MTBF.) 


I 
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• som»>  timo  lias  olapsi'il  in  t)if>  testing  ol  a at  ion  ot  a 

given  unit  tyi'o,  refviiis  aiut  replaiemonts  will  altovt  the  chaiaetej 
of  the  jxipulat  ion,  so  that  the  failute  rate  aiul  the  tepait  late  toj 
the  unit  type  beoome  ovnistant  with  time.  Const  ant  latt's  have  been 
assumed  in  this  analysis. 


J.3  CAU'tUATION  OP  TIMfl-RPlLATEb  PAKAMPTPKi^ 


The  statistic  WrUP  for  a giv«'n  unit  type  of  tin-  TAi'KMS  system  can  b«' 
calculated  from  the  develiH'mental  test  data  .is  follows: 

• Let  the  major  assemld  ies  be  designated  as  CIV,  KMSl,  KSSP, 

RSSE,  Ri^SP,  and  RSSG. 

• Lot  Nn,crc  number  of  units  of  a given  type  functioning  in 

the  CIV  at  the  beginning  of  caleiivl.ii  day  P.  Let  Np  ; Np^Jy.^^2<■ 

Np,FSSP<’  •>'"<  Np.KSSG  «i'P»»'«»'"t  similar  figures 

for  the  other  major  assemblies. 

• Let  Tp^pp^’,*  Tp  |<MS1'  KM.sj'  repiosent  the  houts  for  which 

{xiwer  was  .'ipplved  to  eacli  of  the  m.ijoi  .issemf’l  i«'s  on  calendar  d.iy  P. 

Then  if  no  unit  f.iilures  occvirred,  tiu'  siu'cessful  unit-hours  .ichieved  by 
the  given  unit  type  during  c.ilenil.ir  day  P wc>uld  b«'  given  by 


^%,crc  ''  '^P,crc'  * <Np  v 


n-i.KMSl 


) r. 


(N 


P.RbSG  ■''p.Rs'SC) 


If  Rp,  i is  the  remedy  time  fot  the  i**'  incident  iimilving  this  unit 
type  on  day  P,  where  remedy  involves  eithei  repl.icemi'nt  or  on-site  repair, 
then  the  sum  of  tlie  remedy  t imes  for  the  day 


must  be  subtracted  from  the  expression  for  "successful  unit  hours  if  no 
failures  occurred"  to  compute  actual  successful  unit  lunirs. 

If  the  remedy  time  for  an  incident  extetuls  beyond  one  c.tlendar  day, 
the  number  of  functioning  units,  Np,  in  the  affected  assembly  must  be 
reduced  accordingly  for  subseguent  days  until  the  unit  is  restored. 
Similarly,  if  a unit  that  w.is  not  operating  at  the  beginning  of  a day 
is  restored  during  that  calend.ir  day,  the  number  of  successful  unit-houts 
for  that  day  must  be  incremented  to  leflect  the  lestoi.it  ion. 

For  any  specified  c.ilendai  pet iod,  the  MTPP  for  the  unit  type  can  be 
found  by  computing  the  siu-cessful  unit-hours  accumulated  for  all  the  m.i jot- 
assemblies  throughout  all  the  c.ilendar  days  for  that  period  and  dividing  by 
the  failures  recorded  for  th.it  unit  type  during  the  s.ime  {vriod. 


The  statistic  MTTR  for  a given  unit  type  is  calculated  by  dividing  the 
sum  of  all  completed  repair  times  by  the  number  of  all  completed  repairs 
(Section  2.2,  Chapter  Two). 

Since  the  failure  rate  and  repair  rate  for  a [xapulation  of  one  unit 
type  are  assumed  to  be  constant  with  time,  the  times  between  failure  and 
times  to  repair  for  that  population  are  taken  to  be  exponentially  distrib- 
uted. Tl\erefore,  the  chi-square  formula  is  used  for  the  confidence- 
interval  computations  for  the  MTBF  and  MTTR  estimates.  The  values  presented 
in  this  report  are  given  with  symmetrical,  80  percent  confidence  limits. 

Chapter  Nine  lists  the  LRUs  of  the  TACELIS  system  identified  in  this 
study  by  ARINC  Research  in  cooperation  with  the  Test  Engineer  for  the 
Developmental  Tester.  For  each  identified  unit,  it  presents  estimates  of 
MTBF,  MTTR,  and  unit  reliability  (for  a time  period  of  24  hours),  togetlier 
with  80  percent  symmetric  confidence  limits.  These  data  are  reported  to 
demonstrate  the  methodology  for  the  RAM  assessment  of  the  TACELIS  system, 
but  they  must  be  used  only  to  indicate  general  trends.  These  data  were 
extracted  from  Equipment  Performance  Reports,  which  represent  an  edited 
version  of  the  original  data  record  (tlie  Maintenance  Request) , omitting 
much  useful  information.  Failures  were  categorized  by  calendar  days  only; 
thus  the  time  of  day  at  whicli  failure  occurred  could  not  be  accounted  for. 

An  accurate  record  of  the  actual  numbers  of  each  type  of  unit  deployed  in 
the  various  major  assemblies  could  not  be  obtained  from  the  Developmental 
Tester.  As  a result,  the  computations  in  several  cases  may  not  accurately 
reflect  the  test  situation.  Records  describing  unit  modifications  during 
the  course  of  developmental  testing  are  likewise  not  available  for  this 
study.  Therefore,  caution  must  be  exercised  in  drawing  inferences  from 
the  values  presented  in  this  report. 


3.4  ELIMINATION  OF  BIAS 

In  conducting  the  RAM  analysis  for  developmental  testing  of  the  TACELIS 
system,  the  data-collection  personnel  for  the  Developmental  Tester  will  have 
the  actual  time-of-day  failure  information  for  all  observed  failures,  which 
was  not  available  for  the  analysis  described  in  this  study.  Therefore,  the 
statistic  MTBF  can  be  computed  as  described  in  Section  3.3.  However,  under 
the  current  data-handling  methods,  units  that  fail  unobserved  (i.e.,  during 
the  night  and  on  weekends)  are  reported  as  failing  at  0800  hours  on  the 
first  subsequent  test  day  (demand  time) . This  practice  will  systematically 
introduce  a bias  in  the  calculated  estimate  of  MTBF  from  developmental  test 
data.  A method  for  improving  this  estimate  is  presented  here. 

The  exact  time  at  which  t)ie  unit  failure  occurs  between  the  end  of  one 
test  shift  and  the  beginning  of  another  is  not  observed.  Therefore,  for 
each  case  the  operating  hours  between  the  end  of  the  previous  test  shift 
and  the  time  of  unit  failure  must  be  estimated.  The  procedure  recommended 
is  to  increment  the  operating  hours  credited  to  the  failing  unit  prior  to 
failure  by  the  expected  time  to  failure  for  the  unit,  given  that  failure 
did  indeed  occur  between  the  test  shifts. 
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Let  the  variable  T represent  Time  To  Failure  for  a population  of  a given 
unit  type. 
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The  fraction  of  between-shi  f t failures  occurriiu)  in  the  interval  .10 
is  qiven  by 
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Therefoie  the  function 
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F(0) 
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has  the  desired  property. 

The  expected  value  of  Time  To  Petween-Sh i f t Failure  is 
T, 

Eiei  - J ^ ^ ' fit’)  de 

0 

This  expected  value  can  be  computed  as  follows: 
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This  result  shows  that  the  expected  value  of  Time  To  Petween-Shi f t Failure 
can  be  expressed  in  terms  of  the  statistic  MTBF  for  the  generic  LKU  typo 
as 


E(0)  = MTBF  - 


T 


\T 


- 1 


S 1 IK'O 


T 


= MTBF. 


The  operatinq  hours  credited  to  units  failinq  unobserved  can  be  in- 
cremented by  the  MTBF  value  calculated  for  that  unit  type  from  test  data 
collected  up  to  that  time  reduced  bv  the  correction  term: 


1 


Althouqh  the  failure  data  provided  to  ARINO  Research  did  not  inclvide 
enouqh  information  to  pennit  use  of  this  correction  factor  in  computinq 
MTBF  for  the  TACELIS  Line  Replace..ible  Units,  it  is  recommended  that  the 
Developmental  Tester  use  this  correction  term.  The  data  bank  available  to 
the  Developmental  Tester  for  RAM  vtnalysis  of  the  TAUELIS  system  contains 
enouqh  information  to  apply  this  procedure. 
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ANALYSIS  OF  THE  MAJOR  ASSEMBLIES 


This  chapter  presents  the  reliability  block  diagrams  for  the  major 
assemblies  of  the  TACELIS  system,  together  with  the  corresponding  mathe- 
matical models. 


4.1  RELIABILITY  BLOCK  DIAGRAMS 

Chapter  Three  presented  the  calculation  of  reliability  values  for  all 
the  Line  Replaceable  Units  in  the  TACELIS  system.  The  methodology  for 
using  these  LRU  reliability  values  to  compute  the  hardware  reliability  of 
the  major  assemblies  is  explained  in  this  chapter.  Three  major  assemblies 
were  studied: 

• The  Control  and  Processing  Center  (CPC) 

• The  Remote  Master  Station  (RMS) 

• The  Remote  Slave  Station  (RSS) 

Each  TACELIS  major  assembly  performs  a variety  of  tasks  relating  to 
the  information  collection,  transfer,  processing,  and  recording  capabilities 
required  to  accomplish  the  total  mission  of  the  system.  Theoretically,  at 
amy  given  time  the  level  of  operation  of  a TACELIS  major  assembly  could  vary 
from  "full  up"  (with  every  LRU  functioning  to  specifications) , through  all 
possible  combinations  of  degraded  states  of  these  capabilities,  to  the 
failure  of  all  the  LRUs.  A block  diagraim  con^'igured  for  the  determination 
of  assembly  reliability  is  entirely  dependent  on  the  definition  of  assembly 
failure  chosen  from  this  spectrum  of  possibilities.  A minimum  level  of 
acceptable  assembly  operation  must  be  stated  for  each  capability.  All 
states  exceeding  this  level  are  defined  to  be  system  success.  If  any 
capability  degrades  below  its  defined  minimum  level,  the  assembly  is  con- 
sidered to  fail. 

The  concept  of  redundancy  is  fundamental  to  the  discussion  of  assembly 
failure.  To  develop  this  concept,  redundancy  is  defined  as  the  existence 
within  the  assembly  of  more  than  one  means,  or  path,  for  accomplishing  a 
given  task.  The  functional  diagrams  of  the  TACELIS  major  assemblies  — 

CPC,  RMS,  and  RSS  — have  been  examined  in  detail  by  ARINC  Research  to 
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determine  all  possible  paths  for  successful  assembly  operation.  Wherever 
more  than  one  path  exists  for  the  accomplishment  of  a specific  task,  the 
reliability  diagram  is  drawn  to  show  parallel  paths.  Those  elements  which 
are  essential  to  assembly  operation  and  whose  failure  would  cause  assembly 
failure  are  shown  in  series  with  the  other  system  elements.  The  reliability 
block  diagrams  for  the  CPC,  RMS,  and  RSS  are  shown  in  Figures  4-1,  4-2,  and 
4-3,  respectively. 

The  following  assumptions  have  been  made  in  determining  the  le-'el  of 
system  operation  below  which  failure  is  considered  to  occur: 

• The  Maintenance  Operator  Position  (MOP)  is  essential  for  system 
initialization  and  for  any  necessary  reconfiguration.  While  it  is 
true  that  the  system  could  function  for  a short  time  without  this 
position  once  it  has  been  initialized,  the  next  critical  incident 
requiring  reconfiguration  would  represent  certain  failure.  With 
the  MOP  in  operation,  however,  several  kinds  of  critical  incidents 
can  be  successfully  resolved.  Therefore,  the  MOP  must  remain 
operative  for  success. 

• In  defining  system  success.  Line  of  Bearing  (LOB)  information  is 
required.  Therefore,  at  least  one  Location  Analyst  '’osition  must 
remain  operative. 

• Multi-channel  information  is  not  considered  essential. 

• Only  one  P?MS  branch  is  required  to  remain  in  operation. 

• The  panoramic  (pan)  displays  are  not  considered  necessary;  there- 
fore, the  pan  display  and  pan  preprocessor  hardware  is  not  con- 
sidered essential. 

• The  fault  monitor  function  at  the  MOP  is  not  considered  essential. 

• System  success  is  said  to  occur  if  only  one  of  the  four  frequency 
bands  is  available. 


4,2  THREE-STATE  MODELS 

Each  of  the  three  major  assemblies  has  been  diagrammed  in  such  a way 
that  three  states,  or  levels,  of  operation  can  be  defined  for  the  assembly 
This  has  been  done  (1)  to  show  how  the  state  concept  is  implemented  in  the 
reliability  block  diagrams  and  (2)  to  provide  examples  for  the  discussion 
of  a three-state  model  in  Chapter  Six. 

For  the  Control  and  Processing  Center  three  states  are  defined  as 
follows: 


• State  1.  All  units  essential  to  successful  system  function  (as 
defined  in  Section  4.1)  are  operating. 

• State  2.  A manual  mode  of  operation  is  still  possible.  The  auto- 
matic signal-collection  capability  of  the  TACELIS  system  has  been 


f 


I. 

t 


i 


4-2 


Figure  4-2.  RELIABILITY  DIAGRAM  FOR  THE  REMOTE  MASTER  STATION 


Fro* 


Figure  4-3.  RELIABILITY  DIAGRAM  FOR  THE  REMOTE  SLAVE  STATION 
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lost,  and  bandwidth  coverage  is  obtained  by  tuning  the  system 
receivers  manually. 

• State  3.  Not  enough  equipment  is  operable  to  permit  collection 
and  analysis  of  signals. 

The  three  states  defined  for  the  RMS  show  the  RMS  (1)  functioning 
fully  in  communication  with  the  associated  RSSs,  (2)  functioning  as  an 
RMS  but  unable  to  communicate  with  the  RSSs,  and  (3)  failed. 

Up  to  four  Remote  Slave  Stations  may  be  "daisy-chained"  together  so 
that  each  communicates  only  with  the  two  immediately  adjacent  in  the  chain. 
All  have  the  function  of  collecting  LOB  information  for  the  system.  There- 
fore, even  if  an  RSS  loses  its  LOB  capability,  it  is  left  in  the  chain  to 
relay  information  between  its  two  neighbors.  The  three  states  chosen  to 
define  RSS  capability  reflect  this  fact: 

• State  1.  The  RSS  is  capable  of  collecting  LOB  data,  in  addition 
to  relaying  communications  between  its  two  adjacent  neighbors  in 
the  "daisy-chain". 

• State  2.  The  RSS  has  lost  its  LOB  data-collection  ability  but  is 
left  in  place  to  function  as  a repeater  set. 

• State  3.  The  RSS  cannot  relay  information. 

4 . 3 MATHEMATICAL  MODELS 

In  developing  a mathematical  representation  for  the  reliability  of 
each  of  the  major  assemblies  from  the  block  diagrams,  the  following  notation 
will  be  used: 

= the  probability  of  success,  or  reliability,  of  the  i^*^  Line 
Replaceable  Unit 

= the  probability  of  failure,  or  unreliability,  of  the  i^^  Line 
Replaceable  Unit 

For  all  units  (P^  + Q^)  = 1 

The  reliability  of  n units  in  series  is  Pj^  • P2  . . • 

The  relicibility  of  k units  in  parallel  is  1 - • Q2  . . • 

These  concepts  will  be  expanded  to  develop  the  mathematical  descrip- 
tions of  the  CPC,  RMS,  and  RSS. 
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It  is  emphasized  that  the  expressions  for  assembly  reliability  devel- 
oped in  this  chapter  relate  to  hardware  reliability  only.  The  major  assem- 
blies of  the  TACELIS  system  are  also  vulnerable  to  incidents  of  software 
failure,  which  have  not  been  included  by  the  customer  within  the  scope  of 
this  study.  Assembly  reliability  values  for  a 24-hour  mission  time  are 
given  in  Chapter  Nine. 
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4.4  RELIABILITY  OF  THE  CPC 


The  formula  for  the  reliability  of  the  Control  and  Processing  Center 
is  given  here  with  reference  to  Figure  4-1  (it  is  emphasized  that  this 
description  of  the  assembly  considers  hardware  only) : 
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•l.b  RELIABILITY  OK  THE  RSS 


The  equation  for  the  reliability  of  the  Remote  Slave  Station  is 
developed  with  reference  to  Kiqure  4-3; 
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Kor  the  LOB  data-col lect ion  function,  these  additional  factors  must  be 
included  in  the  product: 
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~ NOTOH  kilter)  (''1OS2) 


4.7  SENSITIVITY  ANALYSIS 

It  is  obvious  that  the  process  of  calculating  ^vrc  > *^RMS'  *^RSS 

from  the  given  formulas  is  a tedious  one.  To  recalculate  each  time  it  is 
desirable  to  assess  the  effect  of  modi  f icat  ions  on  asseml-)ly  reliability 
wi^uld  be  unnecessarily  time-consuming.  However,  conveniently  chosen  seq- 
mt'nts  of  tlu'  block  diagr.in:  may  be  ex.imined  independently. 

Kor  any  asseml’ly  consisting  of  three  units  A,  B,  and  C connected  in 
series,  the  reliability  of  the  assembly  R;yiip  is  given  by 

'' 

ABC  ABC 

Similarly,  the  reliability  of  any  TACELIS  assemlily  can  be  considered  to  be 
the  product  of  the  reliabilities  of  st'veial  segmeitts  constituting  the  as- 
sembly, if  the  .segmt'fit.s  are  .so  chosen  th.it  thai  are  all  in  .series.  This 
approach  will  be  developed  in  Chapter  Seven  to  show  the  sensitivity  of 
assembly  reliabilities  to  itKidi  f icat  ion . This  approach  permits  the  effect 
of  modification  on  one  tenn  of  t)u'  product  to  be  observed.  The  effect  on 
the  product,  or  total  assembly  reliability,  is  directly  proixirtional . 
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CHAFTt'K  yiVF 


ANALYSIS  OK  THK  TAOKLIS  SYSTKM 


This  I'haptt'i  dosci  ibt's  tho  lol  lability  of  tho  total  TAv'KLlS  systom  as 
a function  of  mission  t imt'. 


5.1  THK  DATA  SASK 

In  OhaKft'f  Koni  the  reliability  of  the  major  as-seml-'l  ies  was  moileli'.l 
alaobra  ical  ly  frimi  the  stinly  of  reliability  block  ^liaai.ims  viescribinq  the 
LRUs,  or  hardwaie  elements,  essential  to  asseml'ly  operation.  This  analysis 
was  performed  to  deiTK-)nst  rat  e the  use  of  block  diaur.ims,  but  it  does  not 
give  a compleft'  description  of  assembly  reliability  since  it  »loes  not 
account  for  software  failures.  Softwaie  f.iilure  incident  leivits  have 
not  been  included  by  the  >.'UStomer  in  the  scov'e  of  this  study. 

The  v.'lironoloij  ical  run  Lhis  from  the  TAULLIS  deve  loj'ment  al  testinu  for 
tho  calendar  period  covered  by  the  Rquipment  Ptuformance  Keixnts  delivered 
to  ARINU  Research  have  been  used  to  develop  .isseml'ly  lel  lability  fiuuies. 

A s.imple  run  loq  sheet  is  shown  in  Fiaure  5-1.  These  run  loas  show  uptime 
and  down  t i mi'  for  each  of  the  ma  jv'i  asseml'lies  fhrouohout  the  first  yeai'  of 
developmental  testina.  Althouah  softwaie  f.iiluie  incivlent  it'fV'rts  were 
not  a part  of  this  study,  the  definitions  tor  assembly  success  that  detei- 
mined  whether  an  asseml'ly  was  considered  to  be  "up"  or  "down"  for  the 
chronoloaical  run  loas  included  software  considerations;  in  fact,  .ilmost 
all  of  the  assembly  failures  ti'i  t raiu;  1 1 ions  to  the  ’Mown"  st.ite'  were 
software-induced.  Therefore,  altlu'uah  these  values  cannot  be  compar"d 
with  the  mi'dels  developed  in  I'hav'ter  Foui  , they  have  been  usevi  foi'  the 
calculation  of  fot.il  system  reliability  since  they  are  mi'ie  repi  esent  at  i ve 
of  the  real  situation  ti.e.,  they  include  sot  t w.ii  e-relat  evl  .isseml'ly  state 
trails  it  ions)  . 

The  statistics  MTRF  .ind  MITR  h.ive  been  developed  foi  the  UFU,  RMS,  aiivl 
RSS  in  a m.innei  .inaloaous  to  th.it  desci  ibed  in  Uh.iptei  Three  for  the  LRUs. 
The  total  .isseml'ly  hours  foi'  e.ich  .isseml'ly  type  h.ive  been  divided  by  the 
number  of  up-to-down  tr.insitions  for  th.it  t yj'e  to  v'loduce  MTUF  v.ilues.  The 
total  downtime  foi'  e.ich  .isseml'ly  type  h.is  been  divided  by  the  lumibei  of 
down-to-up  transitions  foi  th.it  type  to  compute  MTTR  fuiures.  These  results 
are  presented  in  Table  5-1. 
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Figure  5-1.  SAMPLE  OF  CHRONOLOGICAL  RUN  LOG 


Table  5- 

-i . MTBF  AND  MTTR  FOR  THE 

MAJOR  ASSEMBLIES 

Assembly 

MTBF  (Hours) 

MTTR  (Hours) 

CPC 

3.10 

.37 

RMS 

1.80 

.61 

RSS 

1.60 

1.00 

Reliability  values  (.ieveloped  for  the  major  assemlilies  from  these 
statistics  are  giv’eii  in  Table  5-2. 


Table  5-2. 

RELIABILITY  VALUES  FOR  THE 
MAJOR  ASSEMin,IES 

Assembly 

Mission  Time 

1 Hour 

2 Hours 

3 Hours 

CPC 

.72 

. 52 

. 38 

RMS 

.57 

. 33 

.19 

RSS 

.53 

.29 

.15 

The  major  assemblies  of  the  TACEI.IS  intelligence-gathering  system  can 
be  combined  in  several  ways.  The  total  number  of  possible  configurations 
is  determined  by  the  number  of  "building  blocks"  available  to  the  field 
user  of  the  system: 

• 1 Control  and  Processing  Center 

• 2 Remote  Master  Stations 

• 8 Remote  Slave  Stations 

The  allowable  assembly  interfaces  are  governed  by  the  following  rules 

• The  Control  and  Processing  Center  can  be  linked  to  0,  1 , or  2 
Remote  Master  Stations,  as  shown  in  Figure  5-2. 

• Each  of  the  eight  Remote  Slave  Stations  is  equipped  with  three 
data  links,  two  of  which  are  required  for  normal  operation.  The 
third  data  link  is  used  only  when  this  assembly  type  is  designated 
as  a Master  Remote  Slav'e  Station  (MRSS)  and  assigned  the  role  of 
interfacing  between  other  Rt>mote  Slave  Stations  (RSSs)  and  the 
Remote  Master  Station  (RMS) . Communication  between  an  RMS  and  any 
PSS  must  always  be  made  through  an  MRSS. 
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Figure  ^-2.  CPC-RJIS  LINKS 


• Up  to  eight  Remote  Slave  Stations  (one  a designated  Master  Remote 
Slave  Station)  can  be  slaved  to  one  Remote  Master  Station. 

* Each  Remote  Master  Station  can  relay  signals  from  only  one  Master 
Remote  Slave  Station  to  the  Control  and  Processing  Center. 

• Each  Master  Remote  Slave  Station  can  have  no  more  than  two  links 
to  Remote  Slave  Stations. 

* Remote  Slave  Stations  can  be  "daisy-chained". 

5.2  OPTIONS  FOR  THE  CPC- RMS  LINK 

All  possible  options  for  the  CPC-RMS  link  are  illustrated  in  Figure  5-2. 
The  CPC  can  stand  alone,  be  linked  with  one  RMS,  or  be  linked  with  two  RMSs. 
Selected  reliability  values  for  Configuration  2 are  as  follows: 

Mission  Hours  Reliability 

1 .41 

2 .17 

3 .07 
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The  probability  of  rotainini)  at  loast  ono  CPC-RMS  link  in  Conf iquration  3 
is  as  follows: 

Mission  tknits  Ro  1 i .>bi  1 i ty 


5.  3 Ri:i,iAiui,rrY  op  tup  totai.  system 

Tho  ostimatos  of  mission  reliability  foi-  tlu>  total  system  depend  on 
the  system  conf iqurat ion . Mission  re  1 i ab i 1 i t i t's  are  qiven  in  Table  5-3  for 
the  various  conf iqurat ions  shown  in  Fiqure  5-3.  The  definition  of  success 
is  that  lit  least  one  crC’-RMS-KSS  path  must  remain  available.  In  addition, 
two  RSSs  must  remain  functiiuial  and  in  communication  with  an  RMS  so  that 
LOB  information  is  obtained  i>n  inten-epted  siqnals.  The  effect  of  RSS 
redundancy  in  improvinq  reliability  is  apparent.  The  reliability  of  any 
desired  conf iquration  can  be  computed  by  usinq  the  methods  described  in 
Chapter  Pour. 


T.lblo  5-1.  CNP-IKHIR  MIS.SION  KPl.I- 

ABI  LITI  K.S  FOR  TlIRKF. 

TACPI.l. 

; CONFI  lIUKATI  ONS 

Conf iqurat ion 

Rt'  1 i ab i 1 i ty 

Series 

.115 

RMS  Redundancy 

.:a2 

RSS  Reduiulancy 

. 29‘I 

If  difficulties  are  repi'atedly  eneounleri'd  in  improvinq  the  MTBF  values 
for  the  Remote  Slave  Station  assembly,  siqnificant  improvement  in  system 
reliability  can  still  be  obtained  by  usinq  conf i qurat ions  in  which  the 
Master  Remote  Slave  Station  is  linked  to  two  Remote  Slave  Stations.  In 
fact,  for  ful l-strenqth  deployment  of  the  TACPLIS  system,  with  four  RSSs 
reportinq  to  one  RMS,  the  interfaces 


. RSS RSS 


crc RMS  MRSS 


are  always  preferable,  from  a reliability  viewixiint,  to 


Series  Configuration 


RMS  Redundancy  Configuration 


RSS  Redundancy  Configuration 
Figure  5-3.  POSSIBLE  TACELIS  CONFIGURATIONS 
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CIIAI'TKH  SIX 


THREE-STATE  MODEL  FOR  RFTSOLVING 
DEt^RADED  OFERATION 


Tho  TACELIS  systom  can  cont iiuio  to  provide  usofnl  tactical  supjKirt  at 
various  levels  of  deqradation.  To  provide  a RAM  assessment  of  TACELIS 
beyond  tho  usual  two-state  availability  concept,  a three-state  model  is 
developed  in  this  chapter.  The  tliree-state  model  can  bt>  qeiieralized  to  ,i 
more  descriptive  N state  model  at  a later  time  if  reejuired.  Tlie  three- 
state  model  presented  here  is  suffici<’nt  to  provitle  the  basis  for  quantita- 
tive evaluation  of  the  steady-slate  avail.ibil  it  ies  corresfxindinq  to  the 
three  levels  of  TACELIS  operation  as  intniduced  in  Chapter  Four  of  this 
report . 


6.1  MODEL  DEVELOrMi;NT 

To  illustrate  the  followinq  discussion,  Fiquie  6-1  depicts  the  three 
operational  states  identified  foi-  TACELIS; 

• Automated  Mode  - SEAi'S  function  t>p<Mat  ion<)l 

• Manual  Mode  - Manual  tuninq  necessary 

• System  Itown  - Critical  function  lost 


Fiqure  6-1.  TACELIS  STATE  TRANSITION  DIAGRAM 


P-1 


Over  a long  calendar  period,  the  fractions  of  time  that  TACELIS  will 
be  in  states  1,  2,  or  3 (as  shown  in  Figure  6-1)  are  given  by  state  availa- 
bilities /Ky,  A2r  and  A3.  These  availabilities  are  determined  by  the  failure 
and  repair  rates  of  all  system  comjxanents  ( "comfxinents"  generally  means 
LRUs) . 

These  component  failure  and  repair  rates  enter  into  t(ie  formulas  for 
the  A3,  A2,  and  A3  in  terms  of  state  transition  rates  where 

X^j  = the  rate  of  system  degradation  from  state  j to  state  i 

P3j  = the  rate  of  restoration  of  service  from  state  j to  state  i 

The  state  transition  rates  X3.  and  can  in  theory  be  developed  from 

the  reliability  bloclc  diagrams  of  the  TACELIS  major  assemblies  when  the 
failure  and  repair  rates  of  each  system  component  (LRU)  are  Icnown.  This 
computation  is  tedious  if  not  computer-automated.  In  addition,  it  is 
difficult  (but  not  imi-wssible)  to  carry  an  exact  accounting  of  the  uncer- 
tainties in  the  estimates  for  the  many  individual  LRUs  to  confidence  limits 
for  the  transition  rates  X^j,  p^j  and  the  state  availabilities  A3,  A2r  and 
A3.  The  advantage  of  this  direct  method  of  calculating  the  availabilities 
is  that  it  permits  identification  and  evaluation  of  critical  com3>onents, 
together  with  the  effects  of  their  failure  and  repair  rates. 

An  alternative  a3>3)roach  is  to  evaluate  the  transition  rates  X3j  and 
p^j  and  the  availabilities  A3,  A2»  and  A3  directly  from  the  existing  devel- 
opmental testing  run  logs.  Let  T3 , T2 , T3  denote  the  accumulated  operating 
times  TACELIS  was  in  states  1,  2,  and  3,  resfiectivoly,  during  a total 
logged  operating  time  T = T3  + T2  + T3.  Then  point  estimates  of  the  A3  are 


A3  = T3/T;  i = 1,  2,  3 

Let  nj3  denote  t)ie  logged  numl>er  of  transitions  from  state  i to  state  j 
(i,  j = 1,  2,  3)  during  the  logged  intervals  T3 , T2 , and  T3.  Then  tlie  six 
transition  rates  Xj3  and  vij3  are  estimated  by 

^ji  “ '^ji/'^i  i = 1,  2;  j = 2,  3;  i j 

pji  = nj3/T3  i = 2,  3;  j = 1,  2;  i ^ j 

6.2  STATE  AVAILABILITY  FORMUIAS 

The  formulas  for  the  state  availabilities  A3,  A2,  and  A3  in  terms  of 
the  transition  rates  are  obtained  by  solving  tiie  steady-state  transition 
equations : 


0 = 

-^1 

(X21  + Xj^j 

+ A2 

UI2 

^ ^^3 

^‘13 

0 = 

Al 

X21 

- A2 

(X32  + U12) 

+ ^3 

V'23 

0 = 

Al 

^31 

+ ^^2 

^32 

- ^3 

(•'2  3 I'Kl 
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subject  to  the  condition  that  the  system  must  always  be  in  one  of  the 
, three  states,  i.e., 

+ A2  + A3  = 1 

The  solution  is  seen  to  be 

Ai  = 3/(Yi  + Y2  + Y3) 

A2  = 2/  ^''*^1  ^2  Y3) 

A3  = 3/(Yi  + Y2  + Y3) 

where,  in  terms  of  and 

'^'l  = bl2  Ul3  + P12  V*23  VJi3  ^32  : 

"'*'2  *^13  ^21  VI23  ^21  ^ Vl23  ^31  [ 

Y3  = b32  ^31  + ^21  ^32  + ^31  ^32  ! 

I 

6.3  APPLICATIONS  OF  STATE  TRANSITION  MODELS  ^ 

The  software  applications  packages  that  control  TACELIS  system  opera-  , 

tion  are  currently  being  modified  too  frequently  to  permit  acquisition  of 
meaningful  data  from  developmental  testing  for  a three-state  availability 
analysis  of  the  TACELIS  system.  Since  the  system  is,  in  effect,  being 
continuously  redefined  with  respect  to  software,  any  quantitative  descrip- 
tion of  the  availability  of  the  many  TACELIS  capabilities  would  be  obsolete  | 

by  the  time  it  could  be  published.  However,  at  a later  state  in  the  devel- 
opment of  the  TACELIS  system,  when  the  hardware  and  software  constituting  ' 

the  system  remain  constant  with  time,  a multiple-state  analysis  of  TACELIS 
availability  as  presented  in  this  chapter  should  be  made.  Since  several  j 

levels  of  degraded  operation  can  be  defined  for  tlie  TACELIS  system,  all  of 
which  may  yield  some  degree  of  useful  information,  the  multiple-state  analy-  1 

sis  provides  a much  more  appropriate  description  of  system  availability. 

Therefore,  the  methodology  has  been  presented  for  future  use. 


I 
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CHAPTER  SEVEN 


RELIABILITY  GROWTH 


In  this  chapter,  the  hardware  reliability  growth  achieved  during  the 
first  11  months  of  developmental  testing  is  analyzed  and  improvement-effort 
allocation  is  discussed. 


7.1  RELIABILITY  GROWTH 

Whenever  a statistical  estimate  is  based  on  a sample  of  ri  data  items, 
such  as  an  MTBF  estimate  based  on  n incident  reports,  the  confidence  that 
the  true  but  unknown  mean  of  an  infinite  population  of  these  data  items 
lies  within  fixed  bounds  about  the  estimate  increases  as  n increases. 
Correspondingly,  for  a given  level  of  confidence,  the  bounded  interval 
about  the  estimate  that  can  be  assumed  to  contain  the  true  but  unknown 
mean  decreases  in  size  as  n increases.  In  short,  a reasonable  number  of 
incident  reports  must  be  available  to  make  a meaningful  estimate  of  MTBF 
and  to  make  statements  about  reliability  growth.  Therefore,  only  those 
Line  Replaceable  Units  for  which  more  than  15  incidents  were  reported  have 
been  studied  to  determine  whether  any  significant  change  in  MTBF  occurred 
during  the  first  11  months  of  developmental  testing. 

The  analytic  approach  involved  computing  a value  MTBF{1)  for  each  LRU 
based  on  the  first  half  of  the  calendar  test  time,  which  contains  all  those 
incidents  reported  through  April  11,  1978.  Symmetrical  80  percent  confidence 
limits  were  developed  for  the  MTBF(l)  estimate  of  the  true  but  unknown  mean 
life  of  the  LRU  type  (see  Figure  7-1).  Then  a value  MTBF(2)  was  calculated 
from  the  second  half  of  the  chronological  test  data.  If  the  MTBF(2)  value 
lay  within  the  80  percent  confidence  interval  about  MTBF(l),  the  result  was 
judged  inconclusive.  If  the  MTBF (2)  value  lay  outside  the  bounds  of  the 
80  percent  confidence  interval  about  MTBF(l),  a significant  change  was 
recorded.  The  results  of  these  calculations  are  presented  in  Table  7-1. 

When  this  analytic  method  is  used,  four  of  the  seven  unit  types  show 
improvement.  Two  units  types  have  declined  in  reliability.  The  results 
for  the  VHF  Receiver  are  inconclusive. 
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In  80  percent  of  the  estimates,  this  in- 
terval will  include  the  true  but  unknown 
mean  of  the  jx)pulation  of  data  items. 


Ijovicr  80  percent 
confidence  limit 


Estimate  of  mean 
for  data  sample 
of  n items 


Upper  80  percent 
confidence  limit 


Range  of 
values  for 
data  items 


Figure  7-1.  CONCEPT  OF  CONFIDENCE  LIMITS 


7.2  LRU  IMPACT  ON  TACELIS  SYSTEM  RI'.LIAUILITY 

For  any  integer  n,  the  following  configuration  is  always  more  reliable 
than  the  single  unit  A: 


The  reliability  diagr,jms  in  Figures  4-1,  4-2,  and  4-3  show  that  the  TACELIS 
system,  with  first-level  capability  and  one  RSS  operational,  can  be  no  less 
reliable  than  118  units  all  in  series,  with 

• 6t>  units  in  the  CPC 

• 29  units  in  the  RMS 

• 23  units  in  the  RSS 

If  each  unit  in  this  hypothetical  series  conf igurat ion  were  required  to 
have  a 24-liour  mission  reliability  of  Rp  or  greater,  then  the  reliability 
of  the  imaginary  system  would  be 


R 2 (Rp) 


118 


Therefore,  by  selecting  all  the  LRUs  from  tlie  equipment  list  with  a 24-hour 
reliability  less  than  R^-,  and  accounting  for  them,  one  can  quickly  identify 
areas  for  hardware  improvement  that  would  guarantee  a TACELIS  CPC-RMS-RSS 
sequence  to  have  a 24-hour  reliability  of  at  least 
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Those  LRUs  which  are  the  poorest  contributors  to  system  reliability 
can  be  identified  by  the  process  of  elimination.  The  lower  cutoff  jxiint 
Kq  for  acceptable  unit  reliability  is  identified  and  those  LRUs  failing  to 
exceed  this  value  are  listed.  The  unit  types  that  are  not  included  in  the 
118  segments  critical  to  the  definition  of  system  success  are  deleted  from 
the  list.  Reliability  is  calculated  for  each  of  the  critical  segments  con- 
taining LRU  types  that  fail  to  meet  the  R^^  standard.  Those  segments  which 
meet  the  R^-,  value  because  of  unit  redundancy  are  dropped  from  consideration. 
The  remaining  segments  are  analyzed  for  allocation  of  the  improvement  effort. 

Table  7-2  lists  LRUs  in  the  TACELIS  system  having  a 2-1-hovir  unit  reli- 
ability of  loss  than  .995.  Tlie  Cartridge  Magnetic  T.ipe  Unit  lias  been  re- 
placed during  developmental  testing  with  a more  reliable  tape-read  system. 
Units  judged  as  being  not  critical  to  TACELIS  system  operation  are: 

• GRC-103  AM-3349 

• c;rc-103  RT-662 

• Pan  Monitor  Switch  S-2109 

• Pan  Processor  Unit  MX-9428 

• VHF  Receiver  1850 

The  following  units  appeal  as  redundant  implementations: 

• CRT  Display  Controller 

• TD-203  Multiplexer 

• Scanner  Control  Panel 

• Time  Division  Demultiplexer 

• Temporary  Storage  Recorder 

• Output  Encoder  Module 

• Output  Decoder  Module 

• Magnetic  Tape  Drive 

Each  of  the  redundant  imv'lementat ions  of  these  units  is  equivalent  to  a 
single  unit  having  greater  than  .995  24-hour  reliability  in  the  currently 
used  assembly  configurations. 

The  following  units  have  not  been  eliminated  from  consideration  and 
are  critical  to  system  operation: 

• 1 liOB  Antenna  in  the  RSS 

• 1 Twin-Channel  Receiver  in  the  RSS 

• 1 RAMTEK  Keyboard  at  the  Location  Analyst  jvsition  in  tlie  CPC 

Any  improvement  in  the  reliability  of  these  three  units  types  will  result 
in  a directly  proportional  improvement  in  system  reli.Uii 1 ity . 
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Table  7-2.  TACELIS  UNITS  HAVING  LOWEST  RELIABILITY 


Unit 

24-Hour  Reliability 

LOB  Antennas 

.9883 

Cartridge  Magnetic  Tape  Unit 

.9888 

CRT  Display  Controller 

.9920 

GRC-103  AM-3349 

.9927 

GRC-103  RT-662 

.9927 

Multiplexer  TD-203 

. 9944 

Pan  Monitor  Switch  S-2109 

.9925 

RAMTEK  Keyboard  GX-IOO-A 

.9814 

Scanner  Control  Panel  C-9112 

.9939 

Time  Division  Demultiplexor  TD-1099 

.9944 

Temporary  Storage  Recorder 

.9631 

Output  Encoder  Module 

.9909 

Output  Decoder  Module 

.9902 

Pan  Processor  Unit  MX-9428 

.9948 

VHF  Receiver  R-1850 

.9944 

ULR/17  Twin  Channel  Receiver  R-1982 

.9906 

Magnetic  Tape  Drive 

.9870 

A more  rigorous  mathematical  technique  would  be  to  use  the  equations 
for  Rcpc>  RrmS'  '^RSS  ‘■developed  in  Chapter  Four  to  compute  the  partial 

derivatives  of  the  assembly  reliability  values  with  respect  to  the  reli- 
ability of  each  critical  LRU.  The  method  presented  in  this  section,  how- 
ever, is  a quick  and  efficient  way  to  detect  trends  during  developmental 
testing. 


7.3  ANALYSIS  OF  ASSEMBLY  SEGMENTS 

The  effect  of  improvement-effort  allocation  on  assembly  reliability 
will  now  be  studied  in  accordance  with  the  discussion  of  sensitivity  analy- 
sis presented  in  Section  4.7.  The  segment  of  the  Control  and  Processing 
Center  containing  the  1840  Magnetic  Tape  Drive  has  been  selected  for  study. 
This  unit  was  allocated  a very  low  MTBF  in  view  of  the  assumption  that  two 
units  were  operating  in  the  CPC  for  a total  of  6,408  tost  hours,  and  seven 
failures  were  reported.  The  segment  of  the  assemlily  being  considered  is 
shown  in  Figure  7-2. 
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Figure  7-2.  SEGMENT  OF  CFC  ASSEMBLY 


Figure  7-3  illustrates  the  reliability  of  the  Magnetic  Tape  Drive 
segment  of  the  CPC  assembly.  Curves  are  given  to  show  varying  degrees,  M, 
of  redundancy.  The  solid  curves  show  reliability  as  a function  of  time 
for  one  path,  two  parallel  paths,  and  three  parallel  paths.  The  dashed 
curves  show  the  reliability  that  would  be  achieved  in  each  case  if  the 
MTBF  value  for  the  1840  Magnetic  Tape  Drive  could  be  improved  from  1830.9 
hours  to  2000  hours.  This  graph  indicates  the  improved  segment  reliability 
that  can  be  achieved  by  increasing  unit  MTBF  or  implementing  redundancy. 


In  general,  graphs  similar  to  Figure  7-3  should  be  prepared  for  units 
with  low  MTBF  values  that  have  a severe  impact  on  system  reliability  during 
developmental  testing  of  a system.  These  graphs  should  illustrate  how 
various  levels  of  redundancy  would  improve  the  reliability  of  the  critical 
system  segment.  The  impact  of  improving  the  MTBF  values  for  elements 
within  the  system  segment  should  also  be  shown.  Re  liability- improvement 
effort  would  be  allocated  on  the  basis  of  a study  of  these  graphs  and 
include  such  considerations  as  cost,  available  space,  and  whether  the 
critical  element  was  GFE  or  CFE. 
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CHAPTER  EIGHT 


SUGGESTED  CHANGES  TO  IMPROVE  RELIABILITY  ASSESSMENT 


This  chapter  enumerates  the  limitations  encountered  by  ARINC  Research 
during  analysis  of  data  recorded  in  the  format  currently  used  by  the  De- 
velopmental Tester.  Recomrendations  for  improving  reliability  documenta- 
tion are  also  discussed. 


8.1  CURRENT  METHODS 

Reliability  data  for  systems  undergoing  developmental  testing  are  cur- 
rently collected  by  the  Developmental  Tester.  Data  are  manipulated  and 
stored  by  a combination  of  clerical  and  computerized  methods  during  testing. 
After  the  information  has  been  evaluated  and  categorized  at  a scoring  con- 
ference, selected  data  are  subjected  to  computer  analysis  to  generate 
reliability  values. 

The  fundamental  data  set  on  which  the  reliability  analysis  is  based 
consists  of  all  the  controlled  maintenance  actions  requested  in  conjunction 
with  developmental  testing.  For  each  occurrence,  test  personnel  fill  out  a 
Maintenance  Request,  DA  Form  2407  (illustrated  in  Figure  8-1) . After  addi- 
tional facts  become  available  from  subsequent  diagnosis  and  maintenance 
action,  the  maintenance  data  are  edited  by  the  Test  Engineer  for  the  Devel- 
opmental Tester  and  compiled  on  an  Equipment  Performance  Report,  DARCOM 
Form  2134.  This  is  the  form  that  is  actually  presented  for  evaluation  at 
the  scoring  conference. 

The  scoring  conference  participants  are  tasked  with  composing  the 
final  list  of  incidents  that  meet  the  standard  definition  of  failure  and 
categorizing  this  list  in  two  ways: 

• Separating  system  from  mission  failures 

• Distinguishing  between  failures  attributable  to  Government- furnished 
equipment  and  contractor-supplied  items 

The  final  data  set,  which  results  from  editing  of  the  original  data  by 
the  Test  Engineer  and  categorizing  of  the  edited  data  by  the  scoring  con- 
ferees, is  used  to  generate  reliability  values. 


USi  TYffW»'U»  Ot  rUNT  f i::miY  on  HAID  %V9I  Af  I WITH  HARD  Rf  NCU  OR  tAU  ROINT  UN 


DA  2407 


M ^ t itl  ul*  <J 


(continued) 


Figure  8-1.  I'MNTENANCE  REQUEST  FORM 


1 


m 


H. J  INH'iKMATlON 

Tilt’  flt'iiiMl  mt't  liotit;  fiu  i I'lit  1 y ust'tl  toi  tiat.i  proi't'sn  i lu)  may  i t'tisi'iiali  1 y 
bt'  applit’d  ti'  systt'ms  luiviiui  a simplf  fnii t i tun  at  ion  oi  to  systoins  loiiiiii  iiu) 
tt'w  ma  i lit  t'lKiiK-o  ai'tions.  I'oi  nyiitomt;  oomixmoti  ot  sovoi  al  di  1 foi  out  noiioi  io 

I. KU  typoM  aiiii  tot  sysitoms  that  it’qviitt'  tuiniottnn;  ma  i nt  t'uanot'  actions,  mot  o 
oftioiont  tiata  pt  ot'otisi  lui  mot  hotls  ato  nooiiod.  To  ohoi'so  hot  woon  olot  it'al 
and  oompnt  ot  ii'oti  mothoils,  a dooision  shiniKi  l>o  mado  basod  ott  t ho  nnmbot  ot 
dittt'tont  I.KU  typos  tiK-lndoil  in  t ho  systom  and  t ho  total  nnmbot  t't  mainto- 
natK'o  ai-t  itin.-i  tonnostod  dutiiui  t ho  f i t st  itKint  h ot  dovo  1 opmont  al  toidiiu). 

I'ot  oxami’lo,  antt>m>itt'd  data  pi  tH-t’s.s  i nq  miqht  lio  t t'l-tiimiiondoti  tin  sysl  oms 
ii>m(\isod  ot  moio  than  ‘ni  dillotont  iionoi  io  I.KU  typos  ot  t'oi  .syo.toms  that 
ait'  oxpootod  to  I t'nu  i t o moto  than  -U'ti  maintonanoo  actions  dm  inn  dovolop- 
mont  a I t ost  i lui . 

IntiitTOat  ion  that  would  havo  boon  u;;oful  lot  t ho  TAi'Kl.lK  i t-l  i al’ t I i t y 
assossmont  has  bt'on  lost  pt  im.ii  ily  in  t hi  t'o  way.s : 

• by  failuio  to  loootd  all  data  ot  im(\'t  vtiu-o  initially  on  t ho 
Maintonanoo  Koiiuost 

• by  toutino  omi.ss.ion  ot  d.ita  not  I'utiontly  inoludod  in  t ho  it'liability 
asst'ssmont  whon  dat  .i  ato  boinq  oompi  It'd  on  t ho  Kquipmt'iit  I'ot  t otmanoo 
Kopot  t 

• by  obsouiinq  i qn  i t ioant  dat  ,i  tti'nih;  in  t ho  oloiioal  manipulation 
v't  data 

Kaoh  ot  thotto  pioblom  atoas  will  bo  disouttsod  in  dotail  in  t ho  tollowinq 
soot  ions . 


b.  l UATA  OOl.IJU'i'U’N 

To  oxtt.ii't  t ho  maximum  j'ossiblo  loliability  inloimation  1 1 om  t ho  t o:;t 
oxpoi  it'iioo , t ho  hi;:toiy  ot  oaoh  pat  t usod  in  t ht'  systom  boinq  ti'sti'd  thiouqh- 
out  both  tunotional  doploymont  and  inouiiod  ma  i nt  t'nanot'  mu::t  bo  totiiovablo 
t'lom  t ho  t t'oot  dod  dat.i.  Thitt  it;  ('I’sttiblo  it  t ho  tolU'winq  two  oonvont  ions 
lift'  obsotvod: 


Tho  oon  I iqut  at  ion  ot  t ho  systom  at  t ho  inooption  of  tt'stinq  must  bo 
oomplotoly  dosoiibod,  statinq  a uniquo  l.KU  typo  and  tho  unit  sot ial 
ntunbot  ooi  i osix’tui  i nq  to  oaoh  addioss  in  tho  i-onf  iqut  at  ii’ii. 

I’ot  oaoh  inoidont  loootdod,  .til  ot  tho  tollowinq  infotm.ttion  must 
bo  obt  .1  i nod  : 

••  I.KU  typo  tusii.tlly  donotod  by  patt  numbot  1 

• • Sot  i.i  1 numbot 

••  l.oi-at  ion  within  !;y:;tom 

••  Timo  of  ooout  1 otu'o 

••  I.KU  typo  ot  1 opl.ioomont  , it  .iny 

••  tlottal  numbot  ot  t op  1 .toomont  , tt  any 
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Wht'ii  all  this  intimnation  is  .ivailahlo,  a varii'ty  of  ilata  sorts 

oaii  Ih'  poifoinu'd  that  may  ta-voal  data  t i t'luh;  [hm  t itu'iit  to  ii-liability  im- 
provomoiit  studios.  'IVo  t'xamplos  of  infoimatioii  loss  of  this  fyiH'  aio  dis- 
I'layod  ill  I'ivHito  tt-J.  tiiio  KqvnpmoiU  I'o  t foi  maiioo  Kopoi  t dosorihos  t lu' 
toimwal  of  oiio  of  t ho  .1.1  Tomixu  .u  y tdoiaqo  Koooidois  in  t ho  systi-m.  Tho 
othoi  i iqxn  t diK'umonts  an  inoivU'iit  involving  iino  of  tho  I'iqht  Ki-ooidi'i 
t’ontrol  Modiilos  di-ployod.  Noitlioi  i o|x>i  t q i vos  a sorial  luimln'r. 

H.-l  DATA  l-iniTINi: 

Uno  iii^Kutant  oatoqoiy  of  i n fo  i m.i  t ion  loutinoly  omittod  in  oompilinq 
data  on  Kquipmont  Poi  foi  manoo  Ki'pin  t s is  t imo-t  adatoil  data.  Kor  ovoiy 
roportod  incidi'iit  .it  loast  tw  t imo  v.ilui's  shoiiKl  In'  roooi  dod : 

• Tho  t imo  roqniiod  to  loston'  t lio  tunotion.il  o.ip.ibility  t hrouqh 
i opl  .loi'inont  I'l  on-si  to  top.iii 

• Tho  t iiiu'  loquiiovl  to  lop.iii  tho  I.KU  if  it  is  i oimwod  .ind  ii'plaoi'd 
by  .1  simi  l.ii  uni  t 

Tho  .ibsonoo  of  t hoso  d.it.i  pi  ovi'iit  s o. iloul.it  ion  I'l  MTTK  tor  o.ioli  I, Kit  in  tho 
TACKldS  systom.  Thosi'  d.it.i,  it  obt  .1 1 n.ib  1 1- , would  piiwido  v.ilu.iblo  KAM 
i nform.it  ion . 

Anothor  diffioulty  inhoiont  in  tho  prosont  oK'rio.il  iiU't hodo loqy  rosults 
from  tho  faot  th.it  sovi'i.il  inoidonts  m.iy  1h'  inoludovl  on  ono  Kquipmont  I'or- 
form.iiu'o  Koport  . In  nxist  o.isos,  su.  h loportiiui  inoludos  only  iiu'idonts 
rol.itinq  to  ono  typo  i’ll  l.KU,  oh.ii  .lot  01  i :*.od  by  .1  oommon  p.irt  numbi'i  but  in- 
oludinq  moro  th.in  ono  sot  i.il  numbot  . A ono-to-oiu'  oor rospondonoo  botwi'on 
o.ioh  incidi’tit  .itki  its  K’oottiod  d.it.i  i t otii  sot  is  lu'ooss.iiy  iH'fi'io  .itiy 
autom.itod  il.it. 1 I'rooossinq  imdliod  o.in  bi'  .ippliod.  Kiquro  H- 1 is  .1  typio.il 
Kquipmont  I'l'r formanoo  Ko(\m  t utinipiiui  sovi't  .il  ii'poitod  iiu-idonts  on  iiiu' 
form. 
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A numbor  of  d.it.i  sortinq  pi  vvossos  m.iy  bo  us.od  to  I'xpiiso  d.ita  t i luids 
of  intorost,  both  tor  loli.ibility  qt  owt  h .in.ilysis  .iiid  for  imprv'vomont -ot  foi  t 
a I loo.it  ion : 
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Tiiiio  history  ot  ono  p.ii  t ioiil.ii  unit  by  sot  i. it  luuiiboi 
Iiu'idont  loootd  ot  oiu'  I.KII  typo  by  p.ii  t iiumboi 
Koli.ibility  of  ono  t.KU  t ypi'  .is  .1  tunot  1011  I'f  t imo 
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1.  Tlie  Temporary  Storage  Recorder  would  not  stop  at  EOT/BOT  marker.  The  unit  was 
removed  and  sent  to  intermediate  maintenance. 

2.  The  incident  occurred  during  the  Tower  Requirements  test. 

3.  Impact  on  testing  was  minimal  since  the  item  was  not  required  for  ongoing  tests. 

4.  The  level  of  maintenance  required  for  removal  was  organirational . 
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1.  The  Recorder  Control  Module  could  not  control  the  appropriate  Temporary  Storage 
Recorders.  Intermediate  maintenance  was  notified. 

2.  The  Incident  occurred  during  TACJAM  Interface  testing. 

3.  The  Impact  on  testing  was  minimal  as  the  Item  was  not  required  for  ongoing  tests. 

4.  The  level  of  maintenance  required  for  Isolation  was  organizational. 
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Figure  8-2.  (continued) 


8-7 


4.  Level  of  maintenance  required  for  niodificalions  was  depot,  for  removal  and  reinstall; 
tlon  was  ovganiialional . 


Figure  8-3.  EXAMI'LK  OF  INCIDENT  OROUDING  ON  ONE  EDR  FORM 
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The  winkload  iin(xised  on  the  Test  Engineer  by  manual  data-handlinq  methods 
precludes  this  type  of  data  analysis  for  systems  requiring  large  numbers  of 
maintenance  actions.  Therefore,  data  trends  of  interest  may  not  be  revealed. 


H.6  IMPROVEMENT  RE(,}UI RI':Mi:NTi; 

To  be  advantageous,  any  changes  in  reliability  documentation  methods 
should  conform  to  certain  basic  philosophies.  The  suggested  improvements 
should  be  sufficiently  comprehensive  to  supivrt  both  developmental  and 
operational  testing  witti  the  same  set  of  data-collection  and  data-analysis 
tools.  They  should  invoke  the  powerful  algoritlimic  iteration  and  list- 
processing  capabilities  of  the  computer.  Finally,  the  effort  required  to 
implement  new  techniques  must  have  a lower  dollar  and  man-hour  value  than 
the  value  of  the  time  and  information  lost  with  the  present  techniques. 


8.7  recommi;nped  methodology 

The  recommended  methodology  for  dealing  with  test  programs  that  gener- 
ate large  quantities  of  maintenance  requests  is  keyed  to  improvement  in 
five  basic  areas: 


• Military  Standard  RAM  coticepts  and  definitions 

• The  test  design  and  overall  test  plan 

• The  incidcnt-re{iort  ing  format 

• The  data  manipulation  techniques 

• The  agenda  for  the  scoring  conference 

These  concepts  must  be  implemented  in  a mantier  that  coordinates  with  a 
computerized  data  .analysis  av'plicable  to  the  results  of  both  developmental 
and  operational  testing. 

Computer  analysis  should  begin  as  soon  as  200  incident  reports  become 
available  from  developmental  testing.  The  analysis  should  be  updated 
periodically  to  support  RAM  improvement  allocation  and  reliability  growth 
analysis.  At  the  time  of  the  scoring  conference,  the  same  compuiter  capa- 
bility should  be  used  to  develop  an  agenda  for  the  scoring  conference. 
Finally,  the  automated  analysis  should  be  capable  of  providing  all  required 
RAM  statistics  based  on  the  results  of  the  scoring  conference. 


8.8  CONCEPTS  AND  DEFINITIONS 

Before  a meaningful  RAN  analysis  procedure  can  be  automated,  the  dis- 
crepancies and  ambiguities  in  the  currently  published  Technical  Manuals, 

Army  Regulations,  and  Military  Standards  must  be  resolved.  The  first  effort 
should  be  to  create  a system  calendar  similar  to  that  shown  in  Figure  2-1 
(Chapter  Two)  containing  all  the  time  divisions  necessary  to  describe  the 


life  of  the  system,  with  particular  attention  to  the  special  practices  ami 
procedures  of  developmental  and  operational  testing.  Then  the  time-related 
parameters  needed  for  a comprehensive  statement  of  system  effectiveness 
should  be  defined  with  reference  to  the  system  calendar. 


8 . 9 TEST  PLAN 

Several  improvements  are  indicated  during  the  planning  phase.  A pro- 
gram must  be  developed  to  provide  all  test  participants  with  an  overview  of 
the  information  flow  from  raw  test  data  to  final  RAM  results.  This  over- 
view is  necessary  among  the  participating  agencies  as  well  as  within  each 
individual  agency.  The  data-col lection  personnel,  the  test  engineer  who 
clerically  manipulates  the  data,  and  the  analyst  who  conducts  the  final 
computer  analysis  are  currently  operating  without  formal  communication, 
although  these  participants  are  within  the  same  (Developmental  Testing) 
agency.  This  isolation  contributes  to  information  loss.  Moreover,  after 
1-1/2  years  of  TACELIS  developmental  testing,  the  Materiel  Developer  has 
not  been  thoroughly  briefed  by  the  Developmental  Tester  on  the  computer 
analysis  techniques  used  by  the  latter  agency.  The  situation  urgently 
requires  improved  lines  of  communication. 

A complete  list  of  the  LRUs  to  be  included  in  the  system  under  test 
should  be  published  for  the  use  of  all  participants  prior  to  testing.  This 
document  should  present  an  unambiguous  description  of  each  LRU  and  sliould 
indicate  in  which  major  assemblies  and  in  whvat  quantities  witliin  eacli  as- 
sembly a particular  LRU  type  is  deployed.  This  list  should  be  periodically 
updated  to  reflect  necessary  substitutions  and  component  modifications. 

All  personnel  involved  in  the  data  collection  and  analysis  effort  sliould 
be  working  from  the  same  list  of  LRUs  and  using  the  same  nomenclature. 

This  is  currently  not  being  accomplished,  witli  tlie  result  that  serious 
difficulty  is  encountered  in  assessing  data  for  improvement-effort  alloca- 
tion prior  to  the  scoring  conference. 

An  initial  description  of  system  configuration  must  be  prepared,  de- 
scribing each  equipment  location  as  a unique  address.  The  part  number  and 
serial  number  of  the  physical  unit  at  each  address  shovild  be  specified  at 
the  start  of  testing.  Particular  attention  should  be  given  to  preserving 
the  histories  of  similar  equipments  in  different  deployment  locations.  Only 
in  this  way  can  some  failure  patterns  influenced  by  maintenance  and  usage, 
environmental  factors,  or  collocated  faulty  equipment  be  isolated. 

It  is  particularly  im^xartant  ttiat  the  nomenclature  system  developed 
permit  a distinction  between  Government  Kurnislied  Equipment  (GFE)  and 
Contractor  Furnished  Equipment  (CFE)  . The  majority  of  the  LRUs  foi'  whicti 
the  highest  numbers  of  incidents  weit'  reported  for  t lii  s study  are  GKK 
(6  out  of  7).  It  must  be  possibh'  for  the  computer  algoritlim  to  make 
accurate  statements  about  the  impact  of  CFE  on  system  reliability  if  im- 
provement effort  is  to  be  properly  allocated.  Therefore,  the  separvite 
contributions  of  GFE  and  CFE  to  system  reliability  must  be  appropriately 
accounted  for. 
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A run  log  should  be  designed  to  preserve  test  activity  data  pertinent 
to  the  RAM  evaluation.  Chronological  data  — including  Julian  date,  elapsed 
total  test  time,  aind  daily  uptime  and  downtime  for  major  assemblies  — 
should  be  recorded  in  a format  directly  translatable  to  computer  input. 

All  substitutions,  modifications,  or  reconfigurations  should  be  recorded 
in  this  run  log,  combined  with  the  elapsed  total  test  time  at  which  they 
are  effected.  Currently,  vendor  modifications  are  reflected  only  as  nomen- 
clature changes  in  the  Equipment  Performance  Reports.  In  this  way,  valuable 
reliability  growth  data  are  lost. 

The  configuration  description,  LRU  list,  and  run  log  formats  must  be 
flexible  enough  to  meet  the  expanded  requirements  of  operational  testing. 


8.10  INCIDENT  REPORTING 

Data-collection  personnel  may  be  handicapped  by  several  factors; 

• Lack  of  motivation  because  they  have  no  overview  of  how  the  data 
will  be  used 

• Lack  of  elementary  RAM  training  in  the  meaning  and  significance  of 
the  data 

• Lack  of  opportunity  to  properly  complete  data  forms  during  a high- 
workload  test  situation 

• Lack  of  appropriate  alternatives  for  describing  a particular  situa- 
tion because  of  the  composition  of  data  forms 

All  personnel  who  will  participate  in  data-collection  during  a planned 
test  should  be  given  a brief  training  course  before  testing  starts.  This 
course  should  include  motivational  statements,  a simple  but  factual  descrip- 
tion of  RAM  statistics,  and  an  overview  of  how  the  test  data  will  be  devel- 
oped and  analyzed.  In  addition,  a human-engineering  effort  should  be 
directed  toward  composition  of  a data-collection  format  that  will  obtain 
the  best  results.  A detailed  study  of  test  procedures  should  be  conducted 
before  this  comprehensive  incident  report  is  designed.  A checklist  or 
multiple-choice  structure  is  probably  the  most  appropriate. 

A single  report  form  should  be  designed  to  accommodate  all  data  relating 
to  one  particular  incident.  It  would  be  used  to  initiate  incident  reporting; 
track  all  subsequent  data,  including  diagnosis  and  maintenance  efforts;  and 
carry  the  data  to  the  computer  analysis  in  a format  identifiable  with  the 
input  of  the  computer  program.  This  procedure  is  intended  to  prevent  infor- 
mation loss  in  a manual  data-editing  step  by  deferring  data  editing  to  a 
computer  sort.  The  proposed  incident  report  form  would  replace  the  Mainte- 
nance Request  and  Equipment  Performance  Report  forms  currently  used. 

To  permit  timely  forwarding  of  information  concerning  incidents  to  the 
Test  Engineer  without  waiting  for  the  addition  of  maintenance  and  repair 
data,  the  format  would  be  implemented  on  multiple  copy  paper.  One  copy. 
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although  still  incomplete,  could  be  promptly  routed  to  the  Test  Engineer 
following  incident  occurrence.  Remaining  copies  could  be  distributed  to 
test  personnel  requiring  the  data  after  all  maintenance  and  repair  informa- 
tion had  been  included. 

The  computer  prograun  would  be  correspondingly  designed  to  process  the 
data  in  various  levels  of  detail.  First-level  processing  would  be  applied 
to  data  immediately  routed  to  the  Test  Engineer  to  support  allocation  of 
reliability  improvement  efforts.  More  detailed  processing  would  augment 
the  initial  RAM  results  when  the  completed  incident  reports  became 
available. 

The  crucial  factor  in  making  this  procedure  efficient  is  the  descrip- 
tion of  exactly  what  constitutes  an  incident.  It  is  necessary  to  construct 
a clear  definition  of  acceptable  operation,  for  both  individual  units  and 
composite  systems,  as  well  as  an  exact  statement  defining  mission  success. 
Whenever  operation  fell  below  this  predetermined  level  of  satisfactory  per- 
formance, an  incident  report  would  be  generated.  The  report  format  should 
be  designed  to  include  parameters  that  permit  computer  analysis  to  distin- 
guish between  the  following: 

• Scheduled  and  nonscheduled  maintenance 

• System  and  mission  failures 

• GFE  and  CFE 

In  the  present  system,  reports  are  generated  during  developmental  and 
operational  testing  for  controlled  maintenance  actions  according  to  the 
schedule  shown  on  the  front  of  DA  Form  2407  (Figure  8-1)  entitled  "Uses  and 
Instructions".  At  the  scoring  conference,  failures  are  categorized  accord- 
ing to  the  Signals  Warfare  Laboratory  publication  Failure  Definition  and 
Scoring  Criteria . The  data  set  subjected  to  the  reliability  analysis  using 
current  methods  is  initially  defined  by  the  maintenance  criteria  and  ulti- 
mately sorted  by  the  failure  definition,  although  these  two  concepts  were 
developed  independently.  With  the  recommended  methodology,  all  the  defini- 
tions by  which  the  data  are  evaluated  during  analysis  should  be  tailored 
to  work  together. 


8.11  COMPUTER  PROGRAM 

The  composition  of  a computer  program  that  would  serve  all  the  require- 
ments of  storage,  sorting,  and  analysis  of  data  for  developmental  and  opera- 
tional testing  is  the  basic  element  of  the  recommended  methodology.  The 
important  characteristic  of  such  a program  is  flexibility . 

Multiple  READ  options  must  be  available  to  accept  the  various  levels 
of  detail  with  which  incidents  would  be  described,  including: 

• The  incomplete  incident  descriptions  forwarded  directly  to  the  Test 
Engineer 
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• The  completed  incident  descriptions,  including  diagnosis  and 
repair  data 

• Incident  descriptions  corresponding  to  all  events  defined  as 
failures  at  the  scoring  conference  with  parameters  categorizing 
failure  chargeability 

The  dimensioning  of  data  storage  arrays  must  be  expandable  to  permit 
the  continuous  addition  of  data  as  testing  progresses.  Data  would  accu- 
mulate in  three  categories  as  follows: 

• The  system  description  will  change  with  reconfiguration,  modifica- 
tion, or  generic  type  replacement. 

• The  chronological  data  from  the  run  log  will  continuously  increase. 

• Incident  descriptions  will  be  added  continuously  to  the  basic  data 
set. 

Therefore,  the  input  format  and  array  structure  for  the  three  data  sets 
described  must  be  designed  to  facilitate  data  additions. 

Several  processing  options  must  be  included  in  the  computer  program  to 
meet  the  differing  requirements  for  analysis  of  improvement-effort  alloca- 
tion, assessment  of  reliability  growth,  preparation  of  scoring  conference 
agenda,  and  computation  of  final  RAM  results.  Most  important,  the  automa- 
tion must  have  a full  edit  capability  for  revising  stored  data  as  correc- 
tions and  reevaluations  are  made. 
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8.12  SCORING  CONFERENCE  AGENDA 

Currently,  the  scoring  conference  examines  the  Equipment  Performance 
Reports  in  exactly  the  order  in  which  they  were  compiled.  Consequently, 
the  discussion  moves  from  one  LRU  type  to  another  in  a disorderly  fashion. 
The  final  recommendation  of  the  proposed  methodology  is  to  sort  the  inci- 
dents by  LRU  type  with  the  computer  program  to  prepare  an  orderly  agenda 
for  the  scoring  conference.  This  agenda  could  be  organized  so  that  all  the 
LRU  types  furnished  by  one  vendor  would  be  considered  consecutively,  and 
that  vendor's  representative  could  be  invited  for  the  appropriate  sequence 
of  the  scoring  conference  only.  All  incidents  relating  to  one  LRU  type 
would  be  discussed  in  the  order  of  their  occurrence  but  separately  from 
those  relating  to  another  LRU  type. 
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CHAPTER  NINE 

CONCLUSIONS 


This  chapter  presents  the  findings  of  the  quantitative  analysis  of  the 
incident  data  and  chronological  run  log  data. 


9.1  THE  LINE  REPLACEABLE  UNITS 

Table  9-1  lists  all  the  Line  Replaceable  Units  of  the  TACELIS  system 
for  which  records  of  incident  data  were  kept  during  the  period  of  develop- 
mental testing  covered  by  this  report.  During  this  period  the  system  was 
not  deployed  at  full-equipment  strength  as  described  in  Chapter  One.  The 
major  assemblies  tested  were: 

• 1 Control  and  Processing  Center 

• 2 Remote  Master  Stations 

• 4 Remote  Slave  Stations 

Table  9-1  shows  the  numbers  of  units  of  each  type  that  were  included  in  the 

major  assemblies.  Each  unit  type  is  categorized  as  GEE  or  CFE  where  this 
information  is  available.  MTBF  and  MTTR  are  given  for  each  unib  type  for 
which  incident  data  were  available.  The  symmetrical  80  percent  confidence 
limits  for  these  MTBF  and  MTTR  estimates  are  also  included  in  Table  9-1. 

A reliability  value  for  a mission  time  of  24  hours  is  given  with  each  unit 
type. 

For  several  unit  types,  no  failures  occurred  during  developmental 
testing.  For  these  unit  types,  the  total  number  of  part-hours  calculated 
according  to  the  methods  presented  in  Chapter  Three  has  been  recorded  in 
place  of  the  MTBF  value.  The  24-hour  mission  reliability  for  these  units 
has  been  included  in  all  computations  as  unity.  Neither  an  MTTR  value  nor 
ciny  confidence  limits  are  given  for  these  units. 

For  some  units,  incident  data  were  reported,  but  not  the  subsequent 
repair  data.  For  these  units,  MTTR  and  the  upper  and  lower  confidence 
limits  on  the  MTTR  estimate  are  omitted. 
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9.2  THE  MAJOR  ASSEMBLIES 


I 


The  lack  of  comjilete  maintenance  data  precludes  the  computation  of 
ac/jicH'e'd  uvji  lubilitij  or  m^iintdiiubi  1 i ti/  for  the  assemblies  of  the  TACELIS 
system.  Therefore,  inheront  avaiUibil  itq  and  ro^air^ibi  1 iti)  have  been  re- 
fxjited  instead.  Table  9-2  lists  the  rol  i^bi  1 i ti/ , inherent  availubi  1 itii , 
and  repair.ibil  itti  for  the  major  assemblies  of  TACELIS.  These  data  are 
based  on  the  chronological  run  logs  for  the  reported  phase  of  TACELIS 
developmental  testing.  Almost  all  of  the  up-to-down  assembly  state  transi- 
tions were  software-induced. 


Table  9-2.  i^lAJOK 

ASSEMBLY  STATI.STICS 

Assembly 

Reliability  for 
One-Hour 

Mission  Time 

1 nlierent 

Avai lability 

Repairability 
for  One-Hour 
Corrective 
Maintenance 

T i me 

CPC 

. 724 

.893 

.933 

RMS 

.574 

, 4 7 

. 806 

RSS 

.535 

.015 

. 999 

Notice  that  even  when  rel  i .rlii  1 i ty  values  for  a system  are  low,  system 
inherent  availability  values  may  be  reae-.onable  bee.  use  ret'a  i rabi  1 i ty  values 
are  close  to  unity. 


9.3  THE  TOTAL  SYSTEM 

A unique  table  of  RAM  statistics  cannot  be  given  foi  the  total  TACELIS 
system  since  the  reliability  of  tlie  total  system  is  different  for  each 
possible  syst<?m  configuration.  However,  it  is  appaient  from  Table  5-1 
(Chapter  Five)  that  the  RSS  assembly  has  the  lowest  MTBE  value  and  the 
largest  MTTR  value  of  the  three  assembly  types  constituting  the  TACELIS 
system.  Correspondingly,  the  RSS  has  the  lowest  assembly  availability,  as 
shown  in  Table  9-2.  Moreover,  at  least  two  RSSs  must  remain  functional  to 
obtain  Line  of  Bearing  information.  An  analysis  of  ttu'  essential  asseml'l  ies> 
for  minimum  TACELIS  operation  — 1 CPC,  1 RMS,  and  2 R.sSs  — reveals  tliat 
the  RSS  is  the  "weakest  link  in  t h<’  cliain". 

9.4  REPORTED  INCIDENTS 

The  greatest  munber  of  incidents  wt'ie  reported  for  tlFE  unit  types. 

Table  9-3  lists  the  10  LRD  types  reipiiring  the  greatest  numl'er  of  mainte- 
nance actions. 

9-5 


L 


'■4 

i 


r 


Tjblo  9-3.  UNIT  TYPES  GENERATING  MOST  INCIDENT 

REPORTS 

Unit  Type 

Number  of 

Equipment 

Incidents 

Procurement 

Temporary  Storage  Recorder 

321 

GFE 

CRT  Display  Controller 

47 

CFE 

VHF  Receiver  1850 

45 

GVK 

Output  Encoder  Module 

22 

GFE 

Output  Decoder  Module 

21 

GFE 

Scanner  Control  Panel 

18 

GFE 

Function  Button  Panel 

16 

GFE 

Pan  Processor  Unit 

14 

GFE 

ARC- 150  Radio 

13 

GFE 

ROLM  Control  Panel 

10 

GFE 

9.5  THREE  UNITS  MOST  CRITICAL  TO  SYSTEM  HARDWARE  RELIABILITY 

The  three  unit  types  having  the  greatest  impact  on  system  liarUware 
reliability  as  identified  from  the  available  developmental  test  data  in 
Section  7.2  (Chapter  Seven)  are: 

• The  LOB  antenna  in  the  RSS 

• The  Twin-Channel  Receiver  in  the  RSS 

• The  RAMTEK  Keyboard  in  tl^e  CPC 

9.6  ASSEMBLY  HARDWARt:  RELIABILITY 

The  24-hour  reliabilities  of  tlie  LRUs  can  be  used  to  calculate  the 
hardware  reliabilities  of  the  TACELIS  major  assemblies.  The  reli^ibility 
equations  in  Chapter  Four,  which  represent  the  reliability  blocl<  diagrams 
of  the  CPC,  RMS,  and  RSS  (Figures  4-1,  4-2,  and  4-1,  respect iv’cl y)  can  be 
solved  by  using  the  LRU  24-tiour  reliabilities  sliown  in  Table  9-1.  Table 
9-4  shows  the  24-hour  hardware  reliabilities  of  ttie  major  assemlilies. 
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Table  9-4.  MAJOR  ASSEMBLY  24-HOUR 

HARDWARE 

RELIABILITIES 

Assembly 

Reliability 

CPC 

Manual  Mode 

0.98019 

SEACS  Mode 

0.94628 

RMS 

0.96449 

With  RSS  Control 

0.96297 

RSS 

0.97202 

With  LOB  Function 

0.94493 

9.7  IMPACT  OF  SOFTWARE- INDUCED  ASSEMBLY  FAILURE 


The  following  results  are  obtained  when  24-hour  first-level  capability 
assembly  reliabilities  for  hardware  only  are  compared  with  similar  values 
based  on  hardware  and  software  failures  combined: 


Assembly 

CPC 

RMS 

RSS 


24-Hour  Hardware 
Reliability 


24-Hour  Hardware/ 
Software  Reliability 


.94628 


.00043 


.96297 


.00000(16) 


.94493 


.00000(03) 


Recommendations  for  improvement  of  these  values  are  presented  in  Chapter 
Ten. 
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CIIAl'TEK  TEN 


RECOMMENDATIONS 


This  chapter  presents  suqqostions  for  improvement-effort  allocation 
nuide  on  the  basis  of  the  conclusions  reported  in  Chapter  Nine. 

10.1  SYSTEM  CONFIGURATION 

The  major  assembly  that  is  most  detrimental  to  TACELIS  system  reli- 
ability is  the  Remote  Slave  Station.  Two  corrective  activities  are 
recommended : 

• The  RSS  must  be  the  focus  of  a concentrated  software  improvement 
effort . 

* The  TACELIS  system  should  be  deployed  wherever  possible  with  re- 
dundant RSS  confiquration.  The  optimum  interface  for  four  RSSs  in 
one  RMS  branch  is 


CPC RMS MRSS 


RSS 


10.2  LOGISTIC  SUPPORT 

The  unit  types  identified  in  Section  9.4  as  havinq  qenerated  tlie 
greatest  numbers  of  maiiitenance  requests  will  (with  the  present  failure 
rates)  have  a seveie  impact  on  the  maintenance  and  supply  procedures  for 
the  TACELIS  system.  For  these  unit  types,  a study  should  be  conducted  to 
choose  timonq  alternative  solutions,  includinq: 

• Modification  and  improvc-nient  of  unit 

• Implementation  of  retlundancy 

• Stocking  of  spares 

• Replacement  of  unit  type 
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10.3  HARDWARE  IMPROVEMENT  ALLOCATION 


The  hardware  improvement  effort  should  be  directed  toward  three  unit 
types : 


• The  LOB  antenna  in  the  RSS 

• The  Twin-Channel  Receiver  in  the  RSS 

• The  RAMTEK  Keyboard  in  the  CPC 

The  currently  suqqested  improvement  effort  is  based  on  the  limited  data 
made  available  for  this  study  and  on  the  definitions  of  system  success  out- 
lined in  Chapter  Four.  Subsequent  reevaluation  with  more  data  and  analysis 
resulting  from  additional  testing  may  alter  this  recommendation. 


10.4  SOFTWARE  IMPROVEMENT 

Software  is  the  major  reliability  problem  for  TACELIS  at  the  present 
stage  of  development.  The  scope  of  this  evaluation  did  not  provide  for  an 
assessment  of  software  reliability  improvement  or  performance  prediction. 
It  is  recommended  that  a software  reliability  assessment  effort  be  intro- 
duced as  part  of  RAM  analysis  during  the  operational  testing  of  TACELIS. 
Planning  for  software  data  collection  and  analysis  should  begin  as  soon  as 
possible  because  the  collection  of  useful  software  incident  data  requires 
appropriate  data  forms  and  instruction  in  their  use.  The  selection  of 
forms  and  training  in  the  use  of  these  forms  could  begin  in  the  present 
development  test  program. 


10.5  LIMITATIONS  OF  DATA 

The  results  piresentcd  in  this  report  are  based  on  the  information 
available  to  ARINC  Research  for  this  study.  This  information  (data  from 
the  first  11  months  of  developmental  testing  of  the  TACELIS  system)  is  in- 
complete at  the  present  time.  The  reader  must  be  aware  that  the  conclusions 
and  recommendations  presented  are  subject  to  change  as  the  following  events 
take  place: 

• More  detailed  data  become  available. 

• Existing  data  are  reinterpreted. 

• Definitions  of  system  success  are  changed. 

• Additional  system  testing  is  conducted. 

Methodologies  for  analyzing  the  data  have  been  developed.  The  ixissi- 
bilities  and  limitations  of  the  tost  procedures  currently  in  use  have  been 
identified.  A preliminary  first  estimate  of  numerical  results  based  on 
early  data  returns  has  been  made.  This  report,  if  used  with  an  understand- 
ing of  the  deficiencies  in  the  data  base  from  which  it  was  developed,  should 
be  a useful  guide  to  planning  for  the  future  of  the  TACELIS  materiel  devel- 
opment process. 


